On Wednesday 13 October 2004 07:35, Dhiman, Gaurav wrote: > Yes it definitely can happen (and I think this is the way to do it) that > SS in process's TSS is initialized to the memory address just next to > task_struct (as the kernel stack can grow downwards till this limit) SS:0 points to 0x00000000 linear address. IOW: SSdescr.base == 0 > while the forking of a process and also sets the SP to the fixed offset > from task_struct from where the kernel stack starts growing downwards > (as you mentioned kernel stack starts from there). Now whenever this > process will be scheduled by the scheduler or a process enters the > kernel mode, CPU's SS and SP registers are re-set to the SS and SP > elements in TSS of that process. On task switch it is unnnecessary if SS does not really change (which is happening 99.9% of the time). At user->kernel mode, yes, CPU loads SS from TSS.ss field. > At the time of scheduling, scheduler also change the TSS descriptor for > that CPU on which the process is going to be scheduled. It changes this > TSS descriptor in GDT to point to the TSS of the selected process. There is no "TSS of the selected process". There is only one TSS per CPU. (Intel didn't plan for this arrangement, but Linux nevertheless uses it). Because of this, scheduler does not "change the TSS descriptor for that CPU on which the process is going to be scheduled". It simply patches some values in current CPU's TSS segment. This is way faster that executing microcoded TSS change. > Correct me if I am wrong. > > [overquoting snipped] -- vda -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
