Richard B. Johnson wrote:
> On Wed, 7 May 2003, Roland Dreier wrote:
>
>
>> Richard> The kernel stack, at least for ix86, is only one, set
>> Richard> upon startup at 8192 bytes above a label called
>> Richard> init_task_unit. The kernel must have a separate stack
>> Richard> and, contrary to what I've been reading on this list, it
>> Richard> can't have more kernel stacks than CPUs and, I don't see
>> Richard> a separate stack allocated for different CPUs.
>>
>>This is total nonsense. Please don't confuse matters by spreading
>>misinformation like this. Every task has a separate (8K) kernel
>>stack. Look at the implementation of do_fork() and in particular
>>alloc_task_struct().
>>
>>If there were only one kernel stack, what do you think would happen if
>>a process went to sleep in kernel code?
>>
>> - Roland
>>
>
>
> No, No. That is a process stack. Every process has it's own, entirely
> seperate stack. This stack is used only in user mode. The kernel has
> it's own stack. Every time you switch to kernel mode either by
> calling the kernel or by a hardware interrupt, the kernel's stack
> is used.
>
> When a task sleeps, it sleeps in kernel mode. The kernel schedules
> other tasks until the sleeper has been satisfied either by time or
> by event.
I don't think this is quite accurate either. I have been reading this
thread, and putting that together with what makes sense to me, I gather
that Linux uses the following stacks:
1) A variable sized user-space stack, one per process (maybe more for
user-level threads?). This is swappable.
2) One 8K kernel stack for each process. This is used for situations
such as when a user process makes a system call that then needs to use a
stack. This has to be separate from the user stack for two reasons:
(a) If the user process borked the user stack pointer, the kernel
still needs to have something valid.
(b) The stack used by the kernel cannot be swappable.
3) One single interrupt stack for hardware interrupts. I don't know how
various CPU's deal with this, so either the CPU knows to use this for
hardware interrupts, or the hardware interrupt starts using the current
process's kernel stack then realizes this and switches over.
At the moment, I'm assuming that when the kernel is preempted, the stack
switched to is one which is the kernel stack for some other process.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:32 EST