请点击 LWN 中文翻译计划，了解更多详情。
Every process in the system occupies a certain amount of memory just by existing. Though it may seem small, one of the more important pieces of memory required for each process is a place to put the kernel stack. Since every process could conceivably be running in the kernel at the same time, each must have its own kernel stack area. If there are a lot of processes in the system, the space taken for kernel stacks can add up; the fact that the stack must be physically contiguous can stress the memory management subsystem as well. These concerns have always provided a strong motivation to keep the size of the kernel stack small.
For most of the history of Linux, on most architectures, the kernel stack has been put into an 8KB allocation — two physical pages. As recently as 2008 some developers were trying to shrink the stack to 4KB, but that effort eventually proved to be unrealistic. Modern kernels can end up creating surprisingly deep call chains that just do not fit into a 4KB stack.
在 Linux 发展历史的大部分时间里，针对大多数的体系架构，内核栈都按照 8KB 的大小进行分配，即两个物理页面。直到 2008 年，一些开发人员 试图将栈缩小到 4KB，但最终证明这种努力是不现实的。现代内核运行中的函数调用栈可能会非常深，导致 4KB 的栈根本无法容纳。
Increasingly, it seems, those call chains don’t even fit into an 8KB stack on x86-64 systems. Recently, Minchan Kim tracked down a crash that turned out to be a stack overflow; he responded by proposing that it was time to double the stack size on x86-64 to 16KB. Such proposals have seen resistance before, and that happened this time around as well; Alan Cox argued that the solution is to be found elsewhere. But he seems to be nearly alone in that point of view.
Dave Chinner often has to deal with stack overflow problems, since they often occur with the XFS filesystem, which happens to be a bit more stack-hungry than others. He was quite supportive of this change:
Dave Chinner 经常需要处理栈溢出的问题，这是由于和其他文件系统比起来，XFS 对内核栈的需求更大，导致 XFS 经常发生此类问题。他 非常支持 扩大栈空间的提议：
8k stacks were never large enough to fit the linux IO architecture on x86-64, but nobody outside filesystem and IO developers has been willing to accept that argument as valid, despite regular stack overruns and filesystem having to add workaround after workaround to prevent stack overruns.
对于 x86-64 上的 linux IO 架构来说，8k 大小的栈从来就不够用，但是文件系统和 IO 之外的开发人员从来就不愿意接受扩大这个值，所以每次栈溢出后只好在文件系统内部提供临时的解决方案。
Linus was unconvinced at the outset, and he made it clear that work on reducing the kernel’s stack footprint needs to continue. But Linus, too, seems to have come around to the idea that playing “whack-a-stack” is not going to be enough to solve the problem in a reliable way:
Linus 一开始不确定是否要按照 Minchan 的建议扩大内核栈，他 解释说 优化内核栈使用的工作仍然需要继续。但是，Linus 似乎也感觉纠结于维持栈的大小对于最终解决问题并不是一个很靠谱的想法：
[S]o while I am basically planning on applying that patch, I _also_ want to make sure that we fix the problems we do see and not just paper them over. The 8kB stack has been somewhat restrictive and painful for a while, and I'm ok with admitting that it is just getting _too_ damn painful, but I don't want to just give up entirely when we have a known deep stack case.
Linus has also, unsurprisingly, made it clear that he is not interested in changing the stack size in the 3.15 kernel. But the 3.16 merge window can be expected to open in the near future; at that point, we may well see this patch go in as one of the first changes.
Linus 明确表示他对在 3.15 内核中引入修改栈大小不感兴趣。但是，可以预料 3.16 的合并窗口很快就会打开；到那时，这个补丁将很可能会成为第一批合入的补丁之一。（译者注，Minchan 对 x86_64 栈空间大小的修改最终还是随 3.15 版本和入了，具体的 commit 可以参考 “x86_64: expand kernel stack to 16K”。）
请点击 LWN 中文翻译计划，了解更多详情。
- LWN 531148: Linux 内核文件中的非常规节
- Linux 内核的代码仓库管理与开发流程简介
- LWN 563185: 优化抢占
- LWN 575497: 我们很快就可以有 Deadline 调度器了吗？
- LWN 808048: KRSI —— 另一个基于BPF的安全模块