A good tradeoff
A good tradeoff
Posted Dec 13, 2024 14:01 UTC (Fri) by roblucid (guest, #48964)In reply to: A good tradeoff by wtarreau
Parent article: The long road to lazy preemption
How is that an improvement on the time slice marking it as a candidate for rescheduling by lazy pre-emption when the scheduler knows something is newly runnable? Only non-interactive long running processes that won't block will need pre-emption on busy systems without idle cores.
As I understand it, you'll see a very small increase to throughput efficiency at the risk of massive increase to latency on a busy system. That was why the full pre-emption and work on voluntary cond_resched was done on uniprocessors decades ago when it really mattered to interactive responsiveness and people became obsessed with the scheduluer eg) BFS (brain f**k scheduler) before CFS with process groups satisfied most people.
In the old days on UNIX the much longer ticks caused blocked processes to have increased priority while the running process lost priority, the scheduler when looking at which thread to preempt can use a similar score to pick on the longest running first.
So what's wrong with having the more complicated logic in the scheduler rather than making the timer tick test an extra flag, rather than unconditionally set a single one on running tasks? Effectively the first time the scheduler fires it can prefer preempting candidates that were previously considered and mark new ones after finding a better victim.
Often the scheduler will have idle cores and not even look at pre-emption, you "over book" a CPU with frequently blocking tasks that share cores and while runing at very low priority long running ones to soak up idle time which as batch jobs simply don't care about latency.
As I understand it, you'll see a very small increase to throughput efficiency at the risk of massive increase to latency on a busy system. That was why the full pre-emption and work on voluntary cond_resched was done on uniprocessors decades ago when it really mattered to interactive responsiveness and people became obsessed with the scheduluer eg) BFS (brain f**k scheduler) before CFS with process groups satisfied most people.
In the old days on UNIX the much longer ticks caused blocked processes to have increased priority while the running process lost priority, the scheduler when looking at which thread to preempt can use a similar score to pick on the longest running first.
So what's wrong with having the more complicated logic in the scheduler rather than making the timer tick test an extra flag, rather than unconditionally set a single one on running tasks? Effectively the first time the scheduler fires it can prefer preempting candidates that were previously considered and mark new ones after finding a better victim.
Often the scheduler will have idle cores and not even look at pre-emption, you "over book" a CPU with frequently blocking tasks that share cores and while runing at very low priority long running ones to soak up idle time which as batch jobs simply don't care about latency.