4K Stacks in 2.6

Traditionally, the Linux kernel has used 8KB kernel stacks on most architectures. That stack must suffice for any sequence of calls that may result from a system call - plus the needs of any (hard or soft) interrupt handlers that may be invoked at the same time. In practice, stack overflows are pretty much unheard of in stable kernels; the kernel developers have long since learned to avoid large automatic variables, recursive functions, and other things which can use large amounts of stack space.

There have been patches circulating for some time now which reduce the kernel stack to 4KB. It is generally understood that the switch to smaller stacks will happen at some point; as a result, much work has recently gone into finding code paths in the kernel which are overly stack-hungry. Part of that effort is simply lots of testing; for that reason, recent -mm kernels no longer even offer an 8KB stack option. The hope is that, if enough people try out the smaller stacks and shake out the bugs, 4KB stacks can be merged into 2.6 in the near future.

The smaller stacks are scary to some people; it is hard to be certain that all of the possible paths through the kernel have actually been tested. 4KB stacks also break binary modules, and the nVidia drivers in particular. So there is a certain amount of pressure to defer this change into 2.7.

One might well wonder why the kernel hackers are trying to put this sort of change into a stable kernel series. The problem with 8KB stacks is that they require an "order 1" memory allocation: two pages which are contiguous in physical memory. Order 1 allocations can be very hard to satisfy once the system has been running for a while; physical memory can become so fragmented that two adjacent free pages simply do not exist. The kernel will try hard to free up pages to satisfy larger allocations; the result can be a slow, painful, thrashing system.

Each process on the system has its own kernel stack, which is used whenever the system goes into kernel mode while that process is running. Since each process requires a kernel stack, the creation of a new process requires an order 1 allocation. So the two-page kernel stacks can limit the creation of new processes, even though the system as a whole is not particularly short of resources. Shrinking kernel stacks to a single page eliminates this problem and makes it easy for Linux systems to handle far more processes at any given time.

Arjan van de Ven also made the interesting claim that the 4KB stacks are actually safer. His reasoning has to do with one other aspect of the 4KB stack patch: it moves interrupt handling onto a separate, dedicated stack. Software interrupts also get their own stack. Since interrupt handling has been moved away from the per-process kernel stack, the amount of space for system call handling remains about the same, and the stack space for interrupts has been increased.

The final decision on the integration of 4KB stacks has not yet been made; there are, seemingly, a few problems which still need to be tracked down. If things settle out, however, this fairly significant change could yet be merged into 2.6.

---

(Log in to post comments)