The behavior of scheduler in L4Linux on ARM architecture
sean0920 at gmail.com
Tue May 19 14:06:32 CEST 2009
Thanks for your reply.
On Tue, May 12, 2009 at 4:38 AM, Adam Lackorzynski <
adam at os.inf.tu-dresden.de> wrote:
> On Sat May 09, 2009 at 15:29:02 +0800, Sean wrote:
> > 1. In L4Linux, the process/thread will map to several L4 Threads. How
> > scheduler in the Linux Server considers user processes in L4Linux
> whether to
> > execute in L4 system ? According to the document, does L4Linux
> > only control the user process whether block or not?
> The document is a bit out-dated regarding this area. The scheduler in
> L4Linux does nothing different than the one in Linux.
> > 2. Based on the L4Linux source code from currently SVN, the behavior
> > schedule() function (kernel/sched.c line 4546) is
> > => If next != prev, call context_switch() function
> > => In context_switch() function (kernel/sched.c Line 2649), it calls
> > architecture dependent function switch_to()
> > => In switch_to() function (arch/l4/include/asm/arch-arm/system.h Line
> > 222), it calls l4x_switch_to() function and __switch_to() function
> > => In l4x_switch_to() function (arch/l4/kernel/arch-arm/dispatch.c
> > 170), it logs the message to Trace Buffer of Fiasco and set
> > l4x_current_process
> > => In __switch_to() function (arch/l4/kernel/arch-arm/switch_to.S Line
> > 5), it store the registers to CPU context of thread_info and load all
> > saved previously
> > Based on the source code analysis, it seems that when the L4Linux
> > scheduler decide to do the context switch, the architecture dependent
> > function __switch_to() will do the register restore and load.
> According to
> > the document, I think the behavior here should set the corresponding
> > status of prev and next user process to block or unblock these L4
> > But here it does low level register restore and reload operations to
> > the current running process directly. It confuses me. Can anyone give
> me any
> > ideas to address this?
> switch_to switches the kernel stack and does nothing with the user state
> of the process. Nowadays only one L4 thread is active at a time, i.e.
> the one whose context is currently active in L4Linux. All others are
> blocked until the Linux scheduler decides to switch to those contexts
> and they're ready to be released.
I had found some articles in mailing list to describe the L4 scheduler.
And I already traced the source code appeared in these articles.
But I still had some questions here.
1. When L4Linux scheduler decides to switch to Task A, the
l4x_user_dispatcher() will execute by restoring registers in function
switch_to(). Is this statement true?
In l4x_user_dispatcher(), it runs l4x_spawn_cpu_thread(0, p, t) to
create a new task first and get into a infinite loop. I am confused at the
thread status of Fiasco here.
Is the task created by l4ts_allocate_task2() a L4 thread ? Is
l4x_user_dispatcher() running in L4Linux main thread, which is l4lx.cpu0 ?
Can you give me any idea about the relationship between l4lx.cpu0 thread
and the thread corresponds to L4Linux user process?
2. What's the difference between task and thread in L4Linux?
> Adam adam at os.inf.tu-dresden.de
> Lackorzynski http://os.inf.tu-dresden.de/~adam/<http://os.inf.tu-dresden.de/%7Eadam/>
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the l4-hackers