Submitted by preetdeep on March 27, 2006 - 8:24am.
hello ,
I am not getting satisfiable answer to the question that why kernel stack for each task is fix(8k each).What will be the problems if stack(kernel stack) size is dynamic in nature.
1) The fixed stack size (of 8KB) is used since almost all the processes (in kernel space) never need more than 8KB of stack space on x86 (unlike user space process stacks which run into MB). This value was arrived-at after several experiments and tests.
2) The task_struct (aka Process Control Block) of each process is stored on the other end of the stack. (task_struct size is around 1.5 to 2KB).
This mechanism would make it easier to get the task_struct address of the current process i.e by simply ANDing the ESP (stack pointer) register with 0xFFFFF000. This eliminates the necessity to maintain the task_struct address in a seperate variable/place. Also since the task_struct address of a process has to be accessed several times, this mechanism improves performance.
3) Dynamic stacks are useful when the upper limit of the stack size is huge/unknown (mostly for user space stacks). Dynamic stacks are slower when compared to fixed-size stacks.
Also, the task_struct address has to be maintained seperately in this case which further drops the performance.
Due to the above reasons, Linux Kernel stacks are restricted to 8KB on x86.
Thanks for the explanation. Small doubt is here. The "struct task_struct" is prensent at the beginning of the stack frame as you mentioned. but i read from
some kernel book that tells "struct thread_info" is stored at bottom of stack
{ i mean starts @ 0 } which contains a pointer to "struct task_struct".
Any specific reason why thread_info structure is maintained at the bottom
of kernel stack instead of task_struct structure.
The earlier post was AFAIK based on slightly old info... it *is* the thread_info struct that's stored at the base of the stack. But thread_info is a super set of the task struct as you see here: http://lxr.linux.no/source/include/asm-i386/thread_info.h#L28
The kernel stacks cannot be dynamic because they are allocated from physical memory, not virtual memory. The stack cannot grow into an additional page because the next page is almost certainly in use for another purpose. The stack cannot be moved (as in realloc) because there are pointers to it.
If the stack and task structure is paged out, there would be no record of the task that would allow you to get the page with the task structure back in. As that page would have to be permanently locked, there is no point in doing the extra book keeping for having the page in virtual memory. Far simpler and faster to put in in physical memory.
Hi!
I've read somewhere it's impossible to do dynamic growing stacks on i386. I believe that's because processor entering fault handler changes stacks only on protection ring change. Due to this problem page fault handler handling stack overflow would have to push processor state on overflowed stack, which in turn would cause another page fault.
Probably this limitation is lifted on x86_64.
Sorry for lack of definite information ;)
Advantages of a Fixed-Stack size in kernel
1) The fixed stack size (of 8KB) is used since almost all the processes (in kernel space) never need more than 8KB of stack space on x86 (unlike user space process stacks which run into MB). This value was arrived-at after several experiments and tests.
2) The task_struct (aka Process Control Block) of each process is stored on the other end of the stack. (task_struct size is around 1.5 to 2KB).
Kernel space stack of a process
--------------------- 8KB (Stack Start)
| stack pointer |
|
|
|
|
|
|
|--------------------|
| task_struct |
--------------------- 0KB
This mechanism would make it easier to get the task_struct address of the current process i.e by simply ANDing the ESP (stack pointer) register with 0xFFFFF000. This eliminates the necessity to maintain the task_struct address in a seperate variable/place. Also since the task_struct address of a process has to be accessed several times, this mechanism improves performance.
3) Dynamic stacks are useful when the upper limit of the stack size is huge/unknown (mostly for user space stacks). Dynamic stacks are slower when compared to fixed-size stacks.
Also, the task_struct address has to be maintained seperately in this case which further drops the performance.
Due to the above reasons, Linux Kernel stacks are restricted to 8KB on x86.
Regards,
Narendra Kiran Chinnam.
thread_info structure ?.
Hi narendrakeran,
Thanks for the explanation. Small doubt is here. The "struct task_struct" is prensent at the beginning of the stack frame as you mentioned. but i read from
some kernel book that tells "struct thread_info" is stored at bottom of stack
{ i mean starts @ 0 } which contains a pointer to "struct task_struct".
Any specific reason why thread_info structure is maintained at the bottom
of kernel stack instead of task_struct structure.
Regards,
Jelari.
stack layout
well, the stack grows/goes backwards!
that's why it's physically on "top" and for the cpu logic it's at the end.
The earlier post was AFAIK
The earlier post was AFAIK based on slightly old info... it *is* the thread_info struct that's stored at the base of the stack. But thread_info is a super set of the task struct as you see here:
http://lxr.linux.no/source/include/asm-i386/thread_info.h#L28
Re: why fix kernel stack size
The kernel stacks cannot be dynamic because they are allocated from physical memory, not virtual memory. The stack cannot grow into an additional page because the next page is almost certainly in use for another purpose. The stack cannot be moved (as in realloc) because there are pointers to it.
why kernel stack is from the
why kernel stack is from the physical memory..it should be frm virtual memory....pls tell reason for ti should be in physical memory......
Kernel stack in physical memory because ...
If the stack and task structure is paged out, there would be no record of the task that would allow you to get the page with the task structure back in. As that page would have to be permanently locked, there is no point in doing the extra book keeping for having the page in virtual memory. Far simpler and faster to put in in physical memory.
Hi! I've read somewhere it's
Hi!
I've read somewhere it's impossible to do dynamic growing stacks on i386. I believe that's because processor entering fault handler changes stacks only on protection ring change. Due to this problem page fault handler handling stack overflow would have to push processor state on overflowed stack, which in turn would cause another page fault.
Probably this limitation is lifted on x86_64.
Sorry for lack of definite information ;)
Jachor