Dear
Now I am studying the scheduler design issue of DROPS including Fiasco and L4Linux. In the reference document, "L4Linux Porting Optimizations", it said that
" In an L4Linux system two schedulers are active. One is in the L4 kernel scheduling all L4 threads including L4Linux processes. The L4 scheduler uses static priorities and schedules threads with the same priority round-robin.
The other scheduler is in the Linux server, deciding which Linux process to run next. L4Linux is designed in a way that from the view of the Linux server multiple user processes can be running in the L4 system. Furthermore, the Linux scheduler can only consider those processes that are blocked in the server. Consequently, the Linux server needs to distinguish between user processes being served by the Linux server and the ones running."
For the behavior of the scheduler in L4Linux, I got some questions below.
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?
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?
Thanks a lot!
Best Regards, Sean
Hi,
On Sat May 09, 2009 at 15:29:02 +0800, Sean wrote:
- 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.
- 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
Dear
Thanks for your reply.
On Tue, May 12, 2009 at 4:38 AM, Adam Lackorzynski < adam@os.inf.tu-dresden.de> wrote:
Hi,
On Sat May 09, 2009 at 15:29:02 +0800, Sean wrote:
- 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.
- 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@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@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi,
On Tue May 19, 2009 at 20:06:32 +0800, Sean wrote:
On Tue, May 12, 2009 at 4:38 AM, Adam Lackorzynski < adam@os.inf.tu-dresden.de> wrote:
- 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.
- 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.
- 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?
switch_to() in the Linux kernel does switch the kernel context, i.e. it switches the kernel stack. It does not touch any user state (registers).
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 ?
Yes, and also an address space (task).
Is
l4x_user_dispatcher() running in L4Linux main thread, which is l4lx.cpu0 ?
Yes.
Can you give me any idea about the relationship between l4lx.cpu0 thread
and the thread corresponds to L4Linux user process?
l4lx.cpu0 is executing the Linux kernel code and the thread of the user processes are executing the user code. l4lx.cpu0 is the fault handler of the user threads and is executing kernel code on behalf of the user code.
- What's the difference between task and thread in L4Linux?
A task is basically an address space in which multiple threads can run in. It's the same meaning as used in L4.
Adam
l4-hackers@os.inf.tu-dresden.de