how big is your stack

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Post Reply
sancho1980
Member
Member
Posts: 199
Joined: Fri Jul 13, 2007 6:37 am
Location: Stuttgart/Germany
Contact:

how big is your stack

Post by sancho1980 »

hi

i was wondering, is there any rule of thumb to figure out how big a stack i have to allocate for my kernel/user mode programs???
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Post by AJ »

Hi,

What I tend to do for user programs is put the stack at the top of "uers-space", which for me is 3GB (kernel space is 3-4GB). As long as the stack does not collide with the heap, it can be just under 3GB long if necessary(!).

For the kernel, I have my binary loaded at 0xC0000000, the heap extends to a maximum of 0xEFFFFFFF (of which it currently uses about 2MB!) and the stack is placed at 0xF0000000. Again, as long as the stack does not collide with the heap, it is allocated as much as it needs.

This does lead to the possibility of a stray recursive function using a lot of RAM before you realise there is a problem (as I haven't got a paging out mechanism yet, it can only keep going until I'm out of physical RAM). I'm pleased to say this hasn't happened yet..

Cheers,
Adam
sancho1980
Member
Member
Posts: 199
Joined: Fri Jul 13, 2007 6:37 am
Location: Stuttgart/Germany
Contact:

Post by sancho1980 »

AJ wrote:Hi,

What I tend to do for user programs is put the stack at the top of "uers-space", which for me is 3GB (kernel space is 3-4GB). As long as the stack does not collide with the heap, it can be just under 3GB long if necessary(!).


Dont understand what you mean. Each user mode program sure needs its own stack placed at a different location, provided were multitasking.

AJ wrote:For the kernel, I have my binary loaded at 0xC0000000, the heap extends to a maximum of 0xEFFFFFFF (of which it currently uses about 2MB!) and the stack is placed at 0xF0000000. Again, as long as the stack does not collide with the heap, it is allocated as much as it needs.




Do you mean the top of the stack is 0xF0000000? Where does the heap start? What do you do with the space above 0xF0000000? Is there any reason why you did it like that? I really cannot imagine how I would possibly need a stack of even several MB's! Correct me if I'm wrong!
User avatar
AJ
Member
Member
Posts: 2646
Joined: Sun Oct 22, 2006 7:01 am
Location: Devon, UK
Contact:

Post by AJ »

sancho1980 wrote:Dont understand what you mean. Each user mode program sure needs its own stack placed at a different location, provided were multitasking.


No. Each task has a separate page directory which is loaded on the task switch. This means that each stack is at 0xC0000000 in virtual memory, but of course, they are at different (dynamically assigned) locations in physical memory. Also, each user program is linked to run at 0x100000. The way this is achieved is via the same method.

sancho1980 wrote:Do you mean the top of the stack is 0xF0000000? Where does the heap start? What do you do with the space above 0xF0000000? Is there any reason why you did it like that? I really cannot imagine how I would possibly need a stack of even several MB's! Correct me if I'm wrong!


The heap start is dynamically assigned by my boot loader, but basically begins above kernel code and boot-time allocated data. That is currently at about 0xC00400000, but this will grow upwards as my kernel size grows, and grow downwards as my kernel is optimised!

I don't need a stack of several MB, but it could potentially be. The task manager keeps track of the heap and stack boundaries for each task. If my stack needs another page allocated, it will be provided there is at least one blank page left between the heap and stack. I'm sorry I can't point you to a code link at the moment, but I am revamping my boot loader and the version currently available for download is just a "hello world" test kernel.

Cheers,
Adam
Post Reply