The behavior of scheduler in L4Linux on ARM architecture

Adam Lackorzynski adam at os.inf.tu-dresden.de
Mon May 11 22:38:27 CEST 2009


Hi,

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 the
>    scheduler in the Linux Server considers user processes in L4Linux whether to
>    execute in L4 system ? According to the document, does L4Linux scheduler
>    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 of
>    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 Line
>    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 regs
>    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 thread
>    status of prev and next user process to block or unblock these L4 threads.
>    But here it does low level register restore and reload operations to change
>    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.




Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/




More information about the l4-hackers mailing list