For now CPUs go to sleep as soon as
- their per-cpu queue is empty
- they are done with whatever they were running
In some cases such overly agressive idling scheme leads to serious performance issues. For example, if there is one posix server thread allocated to the core, it will often wake up for short periods of time. Between those wakeups, CPU will go to idle. In this case, every wakeup of posix server thread will require sending IPI, which is an expensive operation (especially so in VMs).
To fix this problem, dequeue method of ready queue can poll for a short period of time before actually going to sleep using arch-specific instruction. The only question is how to determine the length of this period.
For now CPUs go to sleep as soon as
In some cases such overly agressive idling scheme leads to serious performance issues. For example, if there is one posix server thread allocated to the core, it will often wake up for short periods of time. Between those wakeups, CPU will go to idle. In this case, every wakeup of posix server thread will require sending IPI, which is an expensive operation (especially so in VMs).
To fix this problem,
dequeuemethod of ready queue can poll for a short period of time before actually going to sleep using arch-specific instruction. The only question is how to determine the length of this period.