Re: Question regarding thread_struct

From: Robert Love
Date: Tue Mar 08 2005 - 13:11:37 EST

On Tue, 2005-03-08 at 23:25 +0530, Imanpreet Arora wrote:

> Thanks again, but if the whole of the kernel is restricted to couple of pages.

That is all I said.

The kernel can consume hundreds of megabytes of data if it wants. And
it does.

> Does this mean
> a) the whole of the kernel including drivers is restricted to couple of pages.

No. Each process's stack is a page or two. The rest of the kernel is
free to use a lot of memory.

> b) Or with a more probability, I think what you actually mean is that
> whenever there is an interrupt by any driver it runs in either context
> of the current process or depending upon CONFIG_IRQSTACKS.

Yes, the interrupt runs in the stack of the current process or (given
CONFIG_IRQSTACKS) its own stack. Dynamic memory is free to come from
all over.

> If you could just quote the chapter, in your book which contains
> information about this, that would be more than sufficient.

That explains what, exactly? Kernel stacks are in Ch2 (1ed) and Ch3
(2ed), I think.

> > > b) Or does it mean that a particular stack for a particular
> > > process, can't be resized?

Yes, a process's kernel stack cannot be resized.

> Actually what I asked above was "how exactly does one define and
> differentiate kernel stack", as against "user-stack". I think I always
> knew it but couple of clouds were coming over after reading your first
> mail. Also if each thread has a kernel stack how is it allocated at
> first place (alloc_thread_info)(?)

The user-space stack is handled by user-space. It is tracked by

The kernel stack is handled by user-space. It is stored in esp,
obviously, while inside of the kernel. And, yes, alloc_thread_info()
allocates the stack.

Robert Love

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