McG*_*ory 13 multithreading bsd kernel linux-kernel
Azul Systems有一个支持数千个高速缓存一致CPU的设备.我希望能够深入了解操作系统需要进行哪些更改才能安排数千个同时运行的线程.
Mar*_*bst 15
调度数千个线程并不是什么大问题,但是在数百个CPU上安排它们是.您首先需要的是非常细粒度的锁定,或者更好的是无锁数据结构和算法.当一个CPU执行关键部分时,你不能让200个CPU等待.
制定Linux规模是一个漫长而持续的项目.第一个支持多处理器的Linux内核有一个锁保护整个内核(大内核锁,BKL),这很简单,但可扩展性有限.
随后锁定已经变得更细粒度,即存在许多锁(数千？),每个锁仅覆盖一小部分数据.但是,由于细粒度锁定往往很复杂,并且锁定开销开始消耗性能优势,因此可以采取多大程度的限制,特别是考虑到大多数多CPU Linux系统具有相对较少的CPU.
另一件事是,内核尽可能使用per-cpu数据结构.这非常重要,因为它避免了共享数据的缓存一致性性能问题,当然也没有锁定开销.例如,每个CPU都运行自己的进程调度程序,只需要偶尔进行全局同步.
此外,选择一些具有可扩展性的算法.例如,一些读取主要数据受读取 - 更新 - 更新(RCU)而不是传统互斥锁的保护; 这允许读者在并发更新期间继续.
至于内存,Linux会努力从与进程运行位置相同的NUMA节点分配内存.这为应用程序提供了更好的内存带宽和延迟.
您要求对操作系统进行可能的更改,因此我认为这项工作背后有一个重要的工程团队.
还有一些澄清信息可以帮助定义问题参数:
您需要多少IPC(进程间通信)？
他们真的必须是线程,还是他们可以成为流程？
如果它们是进程,是否可以通过套接字相互通信而不是使用共享内存？
什么是内存架构？你是带有1024个内核的直接SMP,还是还有其他一些NUMA(非统一内存架构)或MMP？你的页面表是什么样的？
只知道关于Azul系统的最小信息,我猜你的IPC很少,而且一个简单的"每个核心运行一个内核"模型实际上可能会很好.如果进程需要相互通信,那么他们可以创建套接字并以这种方式传输数据.您的硬件是否支持此型号？(你可能最终也需要每个核心一个IP地址,并且在1024个IP地址处,这可能很麻烦,虽然它们都可能是NAT,但也许这不是什么大问题).如果当然,这种模式会导致一些低效率,例如额外的页表,以及相当多的RAM开销,甚至可能不被您的硬件系统支持.
即使"每个内核1个内核"不起作用,你也可以运行1024/8内核,并且很好,让每个内核控制8个物理CPU.
也就是说,如果你想在一个拥有1024个内核(只有几个物理CPU)的传统SMP机器中每个核心运行1个线程,那么我希望老式的O(1)调度程序就是你想要的.你的CPU [0]很可能会在内核中占据近100%并进行中断处理,但这对于这个用例来说还不错,除非你需要超过1个内核来处理你的工作负载.
我没有受过教育的猜测是,当处理器处于空闲状态时,每个处理器都有一个运行队列和一个工作窃取算法.我可以看到这在M:N模型中工作,其中每个CPU有一个进程,轻量级进程作为工作项.这会感觉类似于工作窃取线程池,例如Java-7的fork-join库中的线程池.
如果您真的想知道,请选择Solaris Internals或深入了解Solaris内核代码.我还在阅读FreeBSD的Design&Impl,其中Solaris Internals是我列表中的下一个,所以我所能做的就是做出疯狂的猜测.