等待阻塞读取的 Cell/BE SPU 上下文是否仍会被分页到 SPU 上？
考虑 Cell/BE 处理器运行多个 SPU 上下文/线程的情况，其中该数量超过系统上的 SPU 数量。因此，Linux 调度程序将运行给定的上下文，直到到达其时间片末尾，然后将其交换以运行不同的上下文。
在我们的系统中，我们有一些 SPU 上下文在概念上处于“等待”状态 - 我们不希望它们现在运行，但我们希望稍后重新激活它们。因此，我们希望 Linux 调度程序不要交换它们并逐出当前正在运行的其他 SPU 上下文。
我们通过让 SPU 上下文执行 spu_readch 内部函数来实现此等待状态，该函数在来自 PPU 的“信号 1”通信通道中执行阻塞读取。然后，当我们希望唤醒 SPU 上下文时，我们向该通道写入一些内容。
因此，问题是：如果 SPU 上下文正在等待通信通道上的阻塞读取，那么 Linux 调度程序是否会将其分页到 SPU 上，还是调度程序会识别到这一点，并且在有内容写入通道之前不会将其分页？
（如果你能指出 Linux 内核代码中实现此功能的位置，那就加分了！）
Consider the case of a Cell/B.E. processor running a number of SPU contexts/threads, where that number exceeds the number of SPUs on the system. Thus, the Linux scheduler will be running a given context until it gets to the end of its timeslice, and then swapping it out to run a different context.
In our system, we have some SPU contexts that are conceptually in a "wait" state -- we don't want them to be running now, but we want to reactivate them later. Thus, we would like for the Linux scheduler not to swap them in and evict other SPU contexts that are currently running.
We've implemented this wait state by having the SPU context execute a spu_readch intrinsic function, which does a blocking read in the "Signal 1" communications channel from the PPU. Then, when we want the SPU context to wake up, we write something to that channel.
Thus, the question: If a SPU context is waiting on a blocking read on a communications channel, will the Linux scheduler page it onto a SPU anyway, or will the scheduler recognize this and not page it in until something has written to the channel?
(Bonus points if you can point me to the place in the Linux kernel code where this is implemented!)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论