Hello
I am wondering if someone could provide information as to how
thread_struct is kept in memory. Robert Love mentions that it is kept
at the "lowest" kernel address in case of x86 based platform. Could
anyone answer these questions.
a) When a stack is resized, is the thread_struct structure copied onto
a new place?
b) What is the advantage of this scheme as against a fixed "virtual-address"?
c) Also could you kindly point the relevant files which do all this
stuff "shed.c"(?)
TIA
--
Imanpreet Singh Arora
On Tue, 2005-03-08 at 22:34 +0530, Imanpreet Arora wrote:
> I am wondering if someone could provide information as to how
> thread_struct is kept in memory. Robert Love mentions that it is kept
> at the "lowest" kernel address in case of x86 based platform. Could
> anyone answer these questions.
Kernel _stack_ address for the given process.
> a) When a stack is resized, is the thread_struct structure copied onto
> a new place?
This is the kernel stack, not any potential user-space stack. Kernel
stacks are not resized.
> b) What is the advantage of this scheme as against a fixed "virtual-address"?
This is inside of the kernel, not in user-space.
> c) Also could you kindly point the relevant files which do all this
> stuff "shed.c"(?)
See kernel/fork.c and alloc_thread_info() and friends in
<asm/thread_info.h>.
Robert Love
On Tue, 08 Mar 2005 12:13:20 -0500, Robert Love <[email protected]> wrote:
> On Tue, 2005-03-08 at 22:34 +0530, Imanpreet Arora wrote:
>
> > I am wondering if someone could provide information as to how
> > thread_struct is kept in memory. Robert Love mentions that it is kept
> > at the "lowest" kernel address in case of x86 based platform. Could
> > anyone answer these questions.
>
> Kernel _stack_ address for the given process.
>
> > a) When a stack is resized, is the thread_struct structure copied onto
> > a new place?
>
> This is the kernel stack, not any potential user-space stack. Kernel
> stacks are not resized.
This has been a doubt for a couple of days, and I am wondering if this
one could also be cleared. When you say kernel stack, can't be resized
a) Does it mean that the _whole_ of the kernel is restricted to
that 8K or 16K of memory?
b) Or does it mean that a particular stack for a particular
process, can't be resized?
c) And for that matter how exactly do we define a kernel stack?
TIA
--
Imanpreet Singh Arora
On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
> This has been a doubt for a couple of days, and I am wondering if this
> one could also be cleared. When you say kernel stack, can't be resized
>
>
> a) Does it mean that the _whole_ of the kernel is restricted to
> that 8K or 16K of memory?
Actually, 4K or 8K these days for x86. But, no, it means that EACH
PROCESS is constrained to the kernel stack. The stacks are per-process.
The kernel never "runs on its own" -- it is always in the context of a
process (which has its own kernel stack) or an interrupt handler (which
either shares the previous process's stack or has its own stack,
depending on CONFIG_IRQSTACKS).
> b) Or does it mean that a particular stack for a particular
> process, can't be resized?
Yes, I just said that in the previous email. The kernel stack cannot be
resized. It is fixed. It is one or two pages, depending on configure
option. That is, 4 or 8K.
The _user-space_ stack, what the application actually uses, is
dynamically resizable. But we are not talking about that.
> c) And for that matter how exactly do we define a kernel stack?
I don't know what you mean. alloc_thread_info() creates the thread_info
structure and stack.
Robert Love
On Tue, 08 Mar 2005 12:28:42 -0500, Robert Love <[email protected]> wrote:
> On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
>
> > This has been a doubt for a couple of days, and I am wondering if this
> > one could also be cleared. When you say kernel stack, can't be resized
> >
> >
> > a) Does it mean that the _whole_ of the kernel is restricted to
> > that 8K or 16K of memory?
>
> Actually, 4K or 8K these days for x86. But, no, it means that EACH
> PROCESS is constrained to the kernel stack. The stacks are per-process.
> The kernel never "runs on its own" -- it is always in the context of a
> process (which has its own kernel stack) or an interrupt handler (which
> either shares the previous process's stack or has its own stack,
> depending on CONFIG_IRQSTACKS).
Thanks again, but if the whole of the kernel is restricted to couple of pages.
Does this mean
a) the whole of the kernel including drivers is restricted to couple of pages.
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.
If you could just quote the chapter, in your book which contains
information about this, that would be more than sufficient.
> > b) Or does it mean that a particular stack for a particular
> > process, can't be resized?
>
> Yes, I just said that in the previous email. The kernel stack cannot be
> resized. It is fixed. It is one or two pages, depending on configure
> option. That is, 4 or 8K.
>
> The _user-space_ stack, what the application actually uses, is
> dynamically resizable. But we are not talking about that.
>
> > c) And for that matter how exactly do we define a kernel stack?
>
> I don't know what you mean. alloc_thread_info() creates the thread_info
> structure and stack.
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)(?)
Thanks.
--
Imanpreet Singh Arora
On Tue, 8 Mar 2005, Imanpreet Arora wrote:
> On Tue, 08 Mar 2005 12:13:20 -0500, Robert Love <[email protected]> wrote:
>> On Tue, 2005-03-08 at 22:34 +0530, Imanpreet Arora wrote:
>>
>>> I am wondering if someone could provide information as to how
>>> thread_struct is kept in memory. Robert Love mentions that it is kept
>>> at the "lowest" kernel address in case of x86 based platform. Could
>>> anyone answer these questions.
>>
>> Kernel _stack_ address for the given process.
>>
>>> a) When a stack is resized, is the thread_struct structure copied onto
>>> a new place?
>>
>> This is the kernel stack, not any potential user-space stack. Kernel
>> stacks are not resized.
>
> This has been a doubt for a couple of days, and I am wondering if this
> one could also be cleared. When you say kernel stack, can't be resized
>
Every task (process) has its own stack which can be as large as
necessary. It grows down towards the user data.
When a user calls the kernel, the kernel code switches to
a 'kernel stack' which is a separate stack and there is a
different one for each and every task on the system. Since,
with thousands of tasks, there will be thousands of kernel stacks,
it is essential to make the kernel stack as small as possible.
In the ix86, this has meant either 1 or two pages of PAGE_SIZE
length (0x1000 currently).
>
> a) Does it mean that the _whole_ of the kernel is restricted to
> that 8K or 16K of memory?
>
All code that executes in the kernel must use the stack that has
already been allocated for it. If you have code that cares about
the size of the kernel stack, the code is broken. If you have
an array, allocated in the kernel, that's longer than a few
hundred bytes, you use kmalloc() or other kernel allocators
for that array.
> b) Or does it mean that a particular stack for a particular
> process, can't be resized?
>
Stacks are never resized and, in fact, this isn't a Unix/Linux
thing, it's just never done because it's stupid and, if necessary,
is used to cover up something equally stupid, like excessive
recursion.
> c) And for that matter how exactly do we define a kernel stack?
>
You don't.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
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.
NO. I did not say this. EACH PROCESS'S KERNEL STACK IS A PAGE OR TWO.
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
mm_struct->start_stack.
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
On Tue, 08 Mar 2005 12:28:42 -0500, Robert Love <[email protected]> wrote:
> On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
>
> > This has been a doubt for a couple of days, and I am wondering if this
> > one could also be cleared. When you say kernel stack, can't be resized
> >
> >
> > a) Does it mean that the _whole_ of the kernel is restricted to
> > that 8K or 16K of memory?
>
> Actually, 4K or 8K these days for x86. But, no, it means that EACH
> PROCESS is constrained to the kernel stack. The stacks are per-process.
> The kernel never "runs on its own" -- it is always in the context of a
> process (which has its own kernel stack) or an interrupt handler (which
> either shares the previous process's stack or has its own stack,
> depending on CONFIG_IRQSTACKS).
CONFIG_IRQSTACKS seems only on ppc64. Is it good to add for other archs too?
Regards
--
Coywolf Qi Hunt
Homepage http://sosdg.org/~coywolf/
On Wed, 2005-03-09 at 02:14 +0800, Coywolf Qi Hunt wrote:
> CONFIG_IRQSTACKS seems only on ppc64. Is it good to add for other archs too?
Some architectures (x86) control per-IRQ stacks via CONFIG_4KSTACKS, so
enabling that directive turns on 4K stacks and gives interrupts their
own stack.
Robert Love
On Wed, 9 Mar 2005, Coywolf Qi Hunt wrote:
> On Tue, 08 Mar 2005 12:28:42 -0500, Robert Love <[email protected]> wrote:
> > On Tue, 2005-03-08 at 22:57 +0530, Imanpreet Arora wrote:
> >
> > > This has been a doubt for a couple of days, and I am wondering if this
> > > one could also be cleared. When you say kernel stack, can't be resized
> > >
> > >
> > > a) Does it mean that the _whole_ of the kernel is restricted to
> > > that 8K or 16K of memory?
> >
> > Actually, 4K or 8K these days for x86. But, no, it means that EACH
> > PROCESS is constrained to the kernel stack. The stacks are per-process.
> > The kernel never "runs on its own" -- it is always in the context of a
> > process (which has its own kernel stack) or an interrupt handler (which
> > either shares the previous process's stack or has its own stack,
> > depending on CONFIG_IRQSTACKS).
>
>
> CONFIG_IRQSTACKS seems only on ppc64. Is it good to add for other archs too?
i386 and x86_64 also have IRQ stacks