I don't pretend to know everything either, and worst.....don't understand very well either: Both asked the same question: http://lkml.org/lkml/2000/10/30/106 http://lkml.org/lkml/2004/5/8/50 And the answer is in Wolfgang book, as copied here (page 104) (u really need to see the diagram): "Intricacies of switch_to" The interesting thing about finish_task_switch is that the cleanups are performed for the task that has been active before the running task has been selected for execution. Notice that this is not the task that has initiated the context switch, but some random other task in the system! The kernel must find a way to communicate this task to the context_switch routine, and this is achieved with the switch_to macro. It must be implemented by every architecture and has a very unusual calling convention: Two variables are handed over, but in three parameters! This is because not only two, but three processes are involved in a context switch. The situation is illustrated in Figure 2-16. Suppose that three processes A, B, and C are running on the system. At some point in time, the kernel decides to switch from A to B, then from B to C, and then from C back to A again. Before each switch_to call, the pointers next and prev located on the stacks of the individual processes are set such that prev points to the currently running process, while next points to the process that will be running next. To perform the switch from prev to next, the first two arguments are completely sufficient for switch_to. For process A, prev points to A and next points to B. A problem arises when A is selected to execute again. Control will return to the point after switch_to, and if the stack were restored to the exact state it had before the switch, prev and next would still point to the same values as before the switch — namely, next=B and prev=A. In this situation, the kernel would not know that process C has actually run before process A. Therefore, the low-level task switch routine must feed the previously executing task to context_switch when a new task is selected. Since control flow comes back to the middle of the function, this cannot be done with regular function return values, and that is why a three-parameter macro is used. However, the conceptional effect is the same as if switch_to were a function of two arguments that would return a pointer to the previously executing process. What switch_to essentially does is prev = switch_to(prev,next) where the prev value returned is not the prev value used as the argument, but the process that executed last in time. In the above example, process A would feed switch_to with A and B, but would obtain prev=C as result. How the kernel implements this behavior depends on the underlying architecture, but it is obvious that the kernel can reconstruct the desired information by considering the kernel mode stacks of both processes — which are naturally simultaneously available to the kernel, which can access all memory at will. And another explanation is also given in UTLK3: http://www.linux-security.cn/ebooks/ulk3-html/0596005652/understandlk-CHP-3-SECT-3.html#understandlk-CHP-3-SECT-3.3 (now this comes with the diagram).....have fun!!! On Mon, Mar 16, 2009 at 4:59 PM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > > On Mon, Mar 16, 2009 at 3:54 PM, Manish Katiyar <mkatiyar@xxxxxxxxx> wrote: > > On Mon, Mar 16, 2009 at 2:20 PM, Mulyadi Santosa > > <mulyadi.santosa@xxxxxxxxx> wrote: > >> On Sat, Mar 14, 2009 at 5:35 PM, Gaurav Tewari <gaurav6969@xxxxxxxxx> wrote: > >>> Hi all, > >>> linux switch_to function which actually does the context switch, very > >>> smartly preserves the 'last' field of prev task_struct across context switch > >>> (the third argument of switch_to()), but where and how does it uses that > >>> argument...or saved value... > >> > >> Understanding The Linux Kernel 3rd edition completely describe it in > >> the "process switching" section. It has something to do with stack > >> juggling.... IIRC it does so, for example when process A goes to B, > >> and when B want to goes back A, the pointer is already saved > >> > >> That's all I could recall this moment...CMIIW people > > > > Is it because we manipulate the stack to save the instruction of the > > next process at the old eip (returning address), so that when the > > stack unwinds it will try to execute the return address and since we > > have the instruction on next process there we switch tasks > > That could be the reason. This is also the part that I don't fully > understand since the early day I learnt about Linux kernel. > > regards, > > Mulyadi. > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx > Please read the FAQ at http://kernelnewbies.org/FAQ > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
