引:为何Linux系统中用于加载内核模块的modprobe指令运行起来慢如牛车？这是为了避免在4096处理器系统中制造出性能瓶颈所致。
一个能与真正的大型机共事的人自然会从中获得不少乐趣，而与别人相比，其更能抢先一步发掘出新的惊喜，这或许正是其中的部分原因！所以很自然的，那些使用SGI服务器系统的家伙们往往比我们中的绝大多数人更能频繁的享受到这样的快感，至于他们目前最新的发现则与一个4096处理器系统上的内核线程数量有关，显然，这样的情形无疑会产生某些有趣的内核运行现象。
最初时候，他们发现自己甚至没法在默认设置下将一个内核启动，Linux系统在任何特定时期内对动态进程数量都有32768个的上限，不管谁只要在当中运行“ps ”(用于显示瞬间进程的动态情况)命令都将会被提示到内核线程正在占据越来越多的槽(slot),而用户编辑器的单处理器桌面正在运行其中的39个。事实上，目前在一个标准系统中就已经有足够的内核线程来填满乃至溢出一台4096处理器设备的最大容量。不过这个问题相对来说也比较容易解决，只要放松对处理器数量的限制即可，但这样一来，又会在某种程度上使情况更趋复杂化。
init进程是系统中所有其它进程(包括内核线程)的启始，所以在一个庞大的系统中，init会拥有众多的子进程，这些子进程依靠一个大的链表来进行维系，这个链表的内容必须通过不同的函数来进行检索，其中包括变量wait ( )，假如被搜索的进程位于链表尾部位置，毫无疑问这会让搜索过程变的很费时间。由于绝大多数内核线程会长时间驻存，新加入的进程自然会被放置在链表后端，可见，搜索的目标进程位于链表后端的可能性比较大。
接下去更有趣的事情发生在将一个模块载入内核的过程中。当新模块将要被链接时，它会调用函数stop_machine_run ( )来加载进程，该函数会为系统中的每个处理器创建一个高优先级的内核线程，线程将会夺取指派给它的CPU资源并一直驻留于此直到被告之退出为止，在所有的处理器均被锁住时，相关联的进程就会被处理。在关键时期内调用诸如stop_machine_run ( )这样的函数确实有些不合乎情理，但是在4096处理器系统中，stop_machine_run ( )将会建立4096个线程，它们中的每一个都会位于init指令子链表的后部，当对其进行整理的时候，这些线程均会被搜索，结果导致系统会完全停滞一段时间。
也许有人会说那么大的系统根本就不应该再允许装载新的模块，但是用户们可能会反对这样的论断，因此在这里我们还需要找到另外一些解决方案，Robin Holt所提供的问题报告(www.linuxworld.com/Articles/229876/)就包括了一个简单的补丁，它可以用来将退出进程移至子链表的开始处，此番改革解决了这个很现实的问题，由此一来，在搜索这些子进程时候无需再反复通过那些虽长期位居前列但却不是目标所指的进程。
Linux之父Linus对此也提出有一些应对办法可供选择，其中之一就是为那些僵尸进程创建一个单独的链表，以完全消除其对搜索过程的影响。另一种方案是停止生成作为init子进程的内核线程，毕竟它们与用户空间没多少关系，但来自某些开发者的想法却认为这种方案真正的关键之处也许是应该减少内核的线程数量。
对于内核线程创建最应负有责任的应该是用于保持未执行任务的等待队列，其在默认状态下会为系统中的每个处理器创建一个线程，虽说在有些情况下用户会从多线程以及处理器当中局部获益，但无庸质疑的是有不少地方并不需要这些线程存在，所以对它们进行清理可以帮助解决一些可预见的问题，作为一个额外的回报这会在ps指令所显示出的列表中平息一些不必要的混乱。
在很多情况下，一个等待队列未必是必需之物，相反，内核子系统仅使用“普通”keventd队列(其运行与缺省线程events/n相仿)即可。虽然在应用keventd线程时不免会碰上一些问题，包括无法确定的潜伏期以及发生机率较小的死锁情况，但是在绝大多数情况下，它的工作状态还是足以让人满意。
而在其它情况下，使用线程则来的更有意义，涉及长时间延迟的任务在此就是一个很好的例子，在keventd队列中运行一个带多二次延迟的函数无疑会被认为是不理智的行为。需要并发关联的操作也得益于其自有线程，但在不少情形下，那些线程并不需要被创建，除非相应的操作已经付诸实施。在大多数系统中运行ps指令都将会显示出涉及到有关错误操作、异步I/O、蓝牙等的线程，在当前的配置下，它们会在启动(或模块加载)的时候被创建，其中多数线程直到系统关闭时也不会进行任何实质性的操作。线程的生成是如此简单，所以有不少线程在有需要的时候只要发出请求便能建立起来。
可以这样认为，在该领域内也许需要进行一些真正意义上的改进，而所有这一切都需要那些有相应的时间与动机的人去完成，与此同时，对于使用4096路系统的用户来讲，他们或许还要为自己的设备添加一两个补丁才行。
