And this option gets less elegant when there are multiple kernel stacks per process. Option 3 seems like it would be the most flexible, but I'm not sure what pitfalls I may encounter if processes start having different kernel memory maps. I think this is what linux does? Option 2 might be a bit more flexible but still requires choosing a maximum stack size and thus has the same issue as option 1 (limited by finite virtual space rather than physical space). Option 1 is simple, but kernel processes need to be very careful not to overflow their stacks (no recursion, etc). Each stack (or at least one per process) can grow down arbitrarily until it hits the heap Option 3: Processes each have their own individual memory map for kernel stack(s). Kernel stacks can grow slightly, until they hit another stack Option 2: Processes share all kernel memory, and kernel stack virtual addresses are spaced out a bit. Option 1: Processes share all kernel memory, and kernel stacks are allocated sequentially in virtual memory. There seem to be at least 3 ways of mapping the kernel stacks that I can envision: using a guard page) and if so, how to implement this. My main question is whether kernel stacks should be allowed to grow beyond their initially allocated size (e.g. I'm a bit confused about how to best manage memory for kernel stack(s) in my 32bit OS.
0 Comments
Leave a Reply. |