[lkml]   [2004]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Kernel stack
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 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]

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.023 / U:5.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site