4K stack to go [LWN.net]

4K stack to go

Posted Apr 18, 2010 21:44 UTC (Sun) by man_ls (subscriber, #15091)
Parent article: Quotes of the week

Pity that some kernel devs (at least Kleen) think that small pages have to go. I would have thought that the right thing to do would be to ensure that 4K pages are enough in any circumstances. Bad recursion algorithms for instance can kill 8K as readily as 4K, so avoiding recursion altogether and giving a hard limit to driver developers looks (to this uninformed non-kernel dev) like good practice.

Maybe keeping the stack within bounds all the time is too hard a problem, but it is a pity to see kernel devs yield to complexity and go back to bigger stacks. We all pay the memory costs, and in some places it really hurts.

(Log in to post comments)

4K stack to go

Posted Apr 24, 2010 19:50 UTC (Sat) by efexis (guest, #26355) [Link]

This is a hard limit to driver developers... you don't get away with overflowing your kernel mode stack. If it occurs on the driver developers machine then great, but if it their system's fine, but the combination of things that go into the running of your machine does overflow the stack, then it's you that gets bit. Outside of the embedded world you'd be hard pressed to find a usage where one single 4k page of RAM, per running process (or kernel thread) would really be described as "paying the memory price" as in most workloads, the amount's tiny. The problem was/is finding two pages next to each other, which is required when running in kernel mode for some reason. As much as it would be nice to be able to save 4k per process, if you've got the memory, which you probably have, it seems somewhat ridiculous to not be able to use some of it to ensure a stable running system, without having to sacrifice things kernel mode preemption in places where allowing the kernel to be preempted by a higher priority task requires stack space that you cannot guarentee despite having plenty of free RAM.

So yeah... two sides 'n all that :-)