The behavior of scheduler in L4Linux on ARM architecture

[Sean]

Dear

Thanks for your reply.

On Tue, May 12, 2009 at 4:38 AM, Adam Lackorzynski <
adam at os.inf.tu-dresden.de> wrote:

> 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.


I had found some articles in mailing list to describe the L4 scheduler.
http://os.inf.tu-dresden.de/pipermail/l4-hackers/2007/003342.html
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?

Thanks!

Best Regards,
Sean


>
>
>
>
> Adam
> --
> 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
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20090519/8ba605a7/attachment.htm>