开发内核以支持多CPU

发布于 2024-07-21 04:27:54 字数 428 浏览 2 评论 0原文

我希望进入操作系统内核开发领域，并认为我的贡献是扩展 SANOS 操作系统以支持多核机器。我一直在阅读有关操作系统的书籍 (Tannenbaum) 以及研究 BSD 和 Linux 如何应对这一挑战，但仍然停留在几个概念上。

当 SANOS 在多个 CPU 上运行时，是否需要拥有更复杂的调度算法，或者当前现有的算法是否可以正常工作？
我知道线程与其启动的核心具有亲和力是一个好主意，但是这是通过调度还是通过更改线程创建方式的实现来处理的？
要使 SANOS 能够在具有数百个内核的计算机上运行，需要考虑什么？据我所知，BSD和Linux最多只能支持十几个核心。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

西瑶 2024-07-28 04:27:55

你的阅读材料很好。所以没有问题。还可以看看斯坦福大学有关操作系统设计的 CS 可下载讲座。

调度算法可能需要更复杂。这取决于正在运行的应用程序的类型以及它们的贪婪程度。他们是自己屈服还是被迫屈服。那种事。这更多的是一个你的流程想要什么或期望什么的问题。 RTOS 的调度比桌面更复杂。
线程应该与一个核心具有亲和力，因为一个进程中的 2 个线程可以并行执行……但不能在同一核心上同时实时执行。将它们放在不同的核心上可以让它们真正并行运行。还可以针对核心关联性来优化缓存。这实际上是线程实现和调度程序的混合。调度可能希望确保线程在核心上同时启动，而不是临时启动，以减少线程相互等待的时间。如果您的线程库是用户空间，它可能会分配核心，或者让调度程序根据容量或最近的死亡情况来决定。
可扩展性通常是内核限制（可以是任意的）。在 Linux 中，如果我记得的话，这些限制是由于调度程序中保存 CPU 信息结构的数组的静态大小造成的。因此它们的大小是固定的。这可以通过重新编译内核来改变。大多数好的调度算法都会支持大量的内核。随着核心或处理器数量的增加，您需要小心，不要对进程执行造成太多碎片。如果一个程序有 2 个线程，请尝试将它们安排在时间接近的位置，因为它们之间可能存在因果关系（通过共享数据）。

您还需要决定如何实现线程，以及如何在内核中表示进程（无论是重进程还是轻进程）。线程是内核管理的吗？用户空间管理？这些事情都会对调度程序设计产生影响。看看POSIX线程在各种操作系统中是如何实现的。有太多东西需要你思考:)

简而言之对于逻辑存在或应该存在的位置，实际上没有任何直接的答案。这一切都取决于设计、应用期望、（程序上的）时间限制等等。

希望这会有所帮助，但我不是这方面的专家。

Your reading material is good. SO no problems there. Also take a peek at the CS downloadable lectures on operating system design from Stanford.

The scheduling algorithm may need to be more sophisticated. This depends on the types of applications running and how greedy they are. Do they yield themselves or are they forced to. That kind of thing. This is more a question of what your processes want, or expect. A RTOS will have more complex scheduling than a desktop.
Threads should have an affinity to one core, because 2 threads in one process can execute in parallel ... but not at the same real-time on the same core. Putting them on different cores allows them to really-run-in-parallel. Also caching can be optimized for core affinity. This is really a mix of your thread implementation and scheduler. The sched may want to ensure threads are started at the same time on cores, rather than ad-hoc to reduce the amount of time threads wait on eachother and things. If your thread library is user-space, maybe it assigns core, or lets the scheduler decide based on capacity or recent deaths.
Scalability is often a kernel limit (which can be arbitrary). In Linux, if I recall, the limits are due to static sizing of arrays that hold CPU information structs in the scheduler. Hence they are a fixed size. This can be changed by recompiling the kernel. Most good scheduling algorithms will support a very large number of cores. As your core or processor count gets higher, you need to be careful that you don't fragment a processes execution too much. If a program has 2 threads, try and schedule them in close-time-proximity because causation may exist (through shared data) between them.

You also need to decide how your threads are implemented, and how a process is represented (be it heavy or lightweight) in the kernel. Are threads kernel managed? user-space managed? These things all have an impact on scheduler design. Look at how POSIX threads are implemented in various operating systems. There is just so much for you to think about :)

in short there are not really any straight-cut answers to where the logic does, or should reside. It is all down to design, application expectation, time-constraints (on the programs) and so on.

Hope this helps, I am not an expert here however.

回复收藏 0 原文

~没有更多了~