On Wed, 7 May 2003, Roland Dreier wrote:
> >>>>> "Richard" == Richard B Johnson <root@chaos.analogic.com> writes:
>
> Richard> On Wed, 7 May 2003, Roland Dreier wrote: The kernel
> Richard> stack, at least for ix86, is only one, set upon startup
> Richard> at 8192 bytes above a label called init_task_unit. The
> Richard> kernel must have a separate stack and, contrary to what
> Richard> I've been reading on this list, it can't have more kernel
> Richard> stacks than CPUs and, I don't see a separate stack
> Richard> allocated for different CPUs.
>
> Roland> This is total nonsense. Please don't confuse matters by
> Roland> spreading misinformation like this. Every task has a
> Roland> separate (8K) kernel stack. Look at the implementation of
> Roland> do_fork() and in particular alloc_task_struct().
>
> Roland> If there were only one kernel stack, what do you think
> Roland> would happen if a process went to sleep in kernel code?
>
> Richard> No, No. That is a process stack. Every process has it's
> Richard> own, entirely seperate stack. This stack is used only in
> Richard> user mode. The kernel has it's own stack. Every time you
> Richard> switch to kernel mode either by calling the kernel or by
> Richard> a hardware interrupt, the kernel's stack is used.
>
> Again, this is nonsense and misinformation. Look at do_fork() and
> alloc_task_struct(). Do you see how alloc_task_struct() is just
> defined to be __get_free_pages(GFP_KERNEL,1) for i386? Do you
> understand that that just allocates two pages (8K) of kernel memory?
> Do you see that it is never mapped into userspace, and that anyway
> a userspace process can use far more than 8K of stack?
>
> That 8K of memory is used for the kernel stack for a particular
> process. When a process makes a system call, that specific stack is
> used as the kernel stack.
I haven't got a clue why and when that code got added. It is
absolutely positively wasted and is not required for kernel system
calls nor interrupts since they all must operate in kernel mode
and, therefore, use the kernel stack.
>
> Richard> When a task sleeps, it sleeps in kernel mode. The kernel
> Richard> schedules other tasks until the sleeper has been
> Richard> satisfied either by time or by event.
>
> Right. Now think about where the kernel stack for the process that is
> sleeping in the kernel is kept.
>
It's the kernel, of course. The scheduler runs in the kernel under
the kernel stack, with the kernel data. It has nothing to do with
the original user once the user sleeps. The user's context was
saved, the kernel was set up, and the kernel will schedule other
tasks until the sleep time or the sleep_on even is complete.
At that time, (or thereafter), the kernel will schedule
the previously sleeping task, its context will be restored, and
it continues execution.
The context of a task (see entry.S) is completely defined by
its registers, including the hidden part of the segments
(selectors) that define priviledge.
> - Roland
> -
> 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/
>
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
-
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