3 ms·
That seems unlikely. The dimensions of the problem space are huge and getting larger. Although the next Linux kernel scheduler I write will be my first, it's
by topspin 3y ago
That seems unlikely. The dimensions of the problem space are huge and getting larger. Although the next Linux kernel scheduler I write will be my first, it's not hard to infer the increase in complexity due to the evolution of CPUs that Linux runs on: "efficiency" cores (now on AMD devices as well), multi-chip modules creating cache locality problems, critical power and thermal management requirements on high power/current devices — all changing concurrently.
- vacuity 3y agoThere certainly isn't one concrete scheduler that works for all workloads. It probably doesn't matter for server or supercomputer environments; as long as some scheduler works, it doesn't have to change. For other use cases, the scheduler should be flexible with throughput and fairness. Priority, resource usage, realtime, but more cohesive. Tuning the scheduler might be harder in such a design, but it should allow for users to not need to switch to a different base entirely. It'd be more of a scheduler framework that can be used to support various workloads dynamically.
- PaulDavisThe1st 3y agoImplicit in all this is the idea that if you do not get the scheduler behaving optimally that it will make a difference sufficient that we can call it a "failure". That's what I'm questioning. Precisely because the dimensions of the problem space have increased, and the raw performance of everything except register save/restore and TLB invalidation has increased, there's wide latitude for scheduling algorithms that are "not quite right".