Nicolas Dichtel 和 Thierry Herbelot 指出，/proc 文件系统中的目录使用链表来识别其文件。但是，当 /proc 目录开始拥有大量文件时，这将变得很慢，例如，当系统需要大量网络套接字时可能会发生这种情况。

Nicolas 和 Thierry 发布了一个补丁，将 /proc 实现更改为使用多个链表而不是只有一个。每个子目录都有自己的链表，键入到目录名称的哈希值。根据他们的基准测试，该补丁节省了遍历给定子目录的所有条目所需时间的 1/5。

Stephen Hemminger 喜欢这种加速，但建议已经有一些实现，例如 hlist 宏，可以简化他们的哈希表代码。

Eric W. Biederman 也喜欢这种加速，并因为在进行其他可扩展性工作时忽略了 /proc 问题而自责。但是，他认为整个链表概念不是正确的方法。特别是，他认为 /proc/net/dev/snmp6 才是 Nicolas 和 Thierry 补丁的真正目标，如果实际上没有人需要该目录中的文件（除了需要极端的向后兼容性的人），那么完全删除它们会更有效。

然而，这在早期的线程中已经出现过，当时 David S. Miller 说过“这可能会破坏工具，这是一个行不通的方案，抱歉。” 因此，不允许重新设计用户界面，这使得 Nicolas 和 Thierry 提出的链表加速成为唯一的选择。但是，Nicolas 说他会考虑使用 rbtree 实现来代替普通的链表，因为 rbtree 可能会更好地扩展。

Minchan Kim 注意到，在 Linux 3.14 下对 qemu-kvm 施加内存压力会导致内核堆栈溢出并导致系统崩溃。他深入研究了代码，并试图减少自己的堆栈使用量，但他无法削减到足以防止崩溃的程度。而且在任何情况下，他说，试图减少每个人的堆栈使用量都不是很可扩展的。他建议将内核堆栈从 8K 扩展到 16K，尽管他承认可能有一些他不了解的不这样做的充分理由。

Dave Chinner 评论说：“8k 堆栈从来都不足以容纳 x86-64 上的 Linux IO 架构，但是文件系统和 IO 开发人员以外的任何人都不愿意接受这个论点，尽管经常发生堆栈溢出，并且文件系统不得不添加一个又一个的解决方法来防止堆栈溢出。”

他补充说，“我们基本上到了必须将每个需要块分配的 XFS 操作推送到另一个线程才能为正常操作获得足够的堆栈空间的地步”，并说“XFS 一直是堆栈使用情况的金丝雀，这个问题基本上是 i386 内核上 4k 堆栈灾难的重演。”

Borislav Petkov 指出，如果他们将内核堆栈从 8K 增加到 16K，无疑会有 16K 也不够用的时候。他想知道是否会有一个极限，或者内核堆栈最终会增长到 1 兆字节甚至更大。

Steven Rostedt 说：“如果 [Minchan 的补丁] 被采纳，它应该是一个配置选项，或者可能由那些需要它的文件系统选择。我不希望在一个没有那么多内存，但只使用 ext2 的机器上使用 16K 堆栈。”

与此同时，H. Peter Anvin 说：“每个线程额外增加 8K 是一个巨大的打击。XFS 确实一直是一个金丝雀，或者说是麻烦点，我怀疑是因为它最初来自另一个内核，而堆栈大小不是一个优化目标。”

大约在这个时候，Linus Torvalds 评论说，像 Minchan 的修复程序这样的东西可能在某个时候是必要的，尽管开发周期已经到了 -rc7，这使得它对于该特定内核版本来说为时已晚。Linus 还指出，在 Minchan 在原始电子邮件中发布的堆栈跟踪中，有很大的空间可以减少堆栈使用量。Linus 评论说：“从快速浏览帧使用情况来看，其中一些似乎是 gcc 在堆栈分配方面做得相当糟糕，但很多只是令人讨厌的调用站点周围的溢出，这些调用站点有大量的参数。很多堆栈槽都被标记为 '%sfp'（据我所知，这是 gcc 的 '溢出帧指针' 的缩写）。”

关于通常如何减少堆栈使用量进行了一次技术讨论（以及进一步考虑了 GCC 可能在某种程度上应该受到责备的方式），但是由于 Linus 愿意接受一个实现更大堆栈的补丁，因此看起来类似于 Minchan 补丁的东西很快将成为内核的一部分。在某个时候，Linus 总结了他对此问题的立场，他说：“Minchan 的调用跟踪和这个线程实际上让我相信，是的，我们真的需要让 x86-64 拥有 16kB 堆栈。[...] 8kB 堆栈在一段时间内一直有些限制和痛苦，我承认它变得太他妈的痛苦了，这没问题。”