4 ms·

To take this work more seriously I miss the discussion of the potential negative effect of their patches. The way it's presented, it gives the false impression

by acqq 11y ago

To take this work more seriously I miss the discussion of the potential negative effect of their patches. The way it's presented, it gives the false impression that "it will just work." However, their premise of "just wake the idle cores as soon as there are threads to run" can actually be harmful in some real-life scenarios, especially regarding the additional power use and the slowdown introduced by switching from the filled to the empty caches. Intuitively, as they demonstrate the "speedup" on some specific programs using some specific patterns I'd expect that some specific programs and patterns exist that don't necessary benefit from every change they present.

caf 11y ago
Well, two out of the four are straight-out bug fixes.
Someone 11y ago
I agree. For the task of writing an OS scheduler, I think the programmers must list desired properties, mathematically prove that their approach has the desired properties and then, but only then, test and measure their implementation for a few CPU years on dozens of types of hardware. And yes, that proof probably will be hairy, but that's precisely the reason it has to happen. Also, in the likely case that the proof is for a limited domain ("at most 1000 CPUs", "level 1 cache shared between the same CPUs as the level 2 cache"), I think the scheduler should test for that at boot time and strongly consider panicking the kernel if it doesn't apply.
- Animats 11y ago
  It may be better to let a task wait briefly on the run queue rather than bringing a processor out of sleep mode. That requires a cost/benefit calculation. That's a lot to ask of a scheduler. Unidirectional interprocess communication forces this issue to come up frequently. The pattern "send on pipe A, wait for pipe B" to a process that is waiting on pipe A and will reply on pipe B implies that, for a very short period between the send and the wait, there are two processes ready to run. Starting one of them on another CPU is suboptimal, and waking up a sleeping CPU is even worse. You're really doing an interprocess subroutine call, but the OS does not know this. (As I point out occasionally, QNX, with MsgSend/MsgReceive and a scheduler that understands them, does this much better.)

by acqq 11y ago

caf 11y ago

Well, two out of the four are straight-out bug fixes.

Someone 11y ago

I agree. For the task of writing an OS scheduler, I think the programmers must list desired properties, mathematically prove that their approach has the desired properties and then, but only then, test and measure their implementation for a few CPU years on dozens of types of hardware. And yes, that proof probably will be hairy, but that's precisely the reason it has to happen. Also, in the likely case that the proof is for a limited domain ("at most 1000 CPUs", "level 1 cache shared between the same CPUs as the level 2 cache"), I think the scheduler should test for that at boot time and strongly consider panicking the kernel if it doesn't apply.

Animats 11y ago
It may be better to let a task wait briefly on the run queue rather than bringing a processor out of sleep mode. That requires a cost/benefit calculation. That's a lot to ask of a scheduler. Unidirectional interprocess communication forces this issue to come up frequently. The pattern "send on pipe A, wait for pipe B" to a process that is waiting on pipe A and will reply on pipe B implies that, for a very short period between the send and the wait, there are two processes ready to run. Starting one of them on another CPU is suboptimal, and waking up a sleeping CPU is even worse. You're really doing an interprocess subroutine call, but the OS does not know this. (As I point out occasionally, QNX, with MsgSend/MsgReceive and a scheduler that understands them, does this much better.)