6 ms·
The long road to lazy preemption in the Linux CPU scheduler
- weinzierl 2y ago"Current kernels have four different modes that regulate when one task can be preempted in favor of another" Is this about kernel tasks, user tasks or both?
- GrayShade 2y agoKernel code, user-space code is always preemptible.
- deleted 2y ago[deleted]
- amelius 2y ago> A higher level of preemption enables the system to respond more quickly to events; whether an event is the movement of a mouse or an "imminent meltdown" signal from a nuclear reactor, faster response tends to be more gratifying. But a higher level of preemption can hurt the overall throughput of the system; workloads with a lot of long-running, CPU-intensive tasks tend to benefit from being disturbed as little as possible. More frequent preemption can also lead to higher lock contention. That is why the different modes exist; the optimal preemption mode will vary for different workloads. Why isn't the level of preemption a property of the specific event, rather than of some global mode? Some events need to be handled with less latency than others.
- acters 2y agoMostly because such a system would install in fighting among programs that all will want to be prioritized as important. tbf it will mostly be larger companies who will take advantage of it for "better" user experience. Which is kind of important to either reduce to a minimal amount of running applications or simply control it manually for the short burst most users will experience. If anything cpu intensive tasks are more likely to be bad code than some really effective use of resources. Though when it comes to gaming, there is a delicate balance as game performance should be prioritized but not be allowed to cause the system to lock up for multitasking purposes. Either way, considering this is mostly for idle tasks. It has little importance to allow it to be automated beyond giving users a simple command for scripting purposes that users can use for toggling various behaviors.
- biorach 2y agoYou're talking about user-space preemption. The person you're replying to, and the article are about kernel preemption.
- withinboredom 2y agoGames run in a tight loop, they don’t (typically) yield execution. If you don’t have preemption, a game will use 100% of all the resources all the time, if given the chance.
- Tomte 2y agoGames run in user space. They don't have to yield (that's cooperative multitasking), they are preempted by the kernel. And don't have a say about it.
- harry8 2y agoMake a syscall for io. Now the kernel takes over and runs whatever it likes for as long as it likes. Do no syscalls. Timer tick. Kernel takes over and does whatever as well. No_HZ_FULL, isolated cpu cores, interrupts on some other core and you can spin using 100% cpu forever on a core. Do games do anything like this?
- simfoo 2y agoCan't find any numbers in the linked thread with the patches. Surely some preliminary benchmarking must have been performed that could tell us something about the real world potential of the change?
- biorach 2y agoFrom the article, second last paragraph: > There is also, of course, the need for extensive performance testing; Mike Galbraith has made an early start on that work, showing that throughput with lazy preemption falls just short of that with PREEMPT_VOLUNTARY.
- spockz 2y agoHow would you benchmark something like this? Run multiple processes concurrently and then sort by total run time? Or measure individual process wait time?
- hifromwork 2y agoI guess both make sense, and a lot of other things (synthetical benchmarks, microbenchmarks, real-world benchmarks, best/average/worst case latency comparison, best/average/worst case throughput comparison...)
- Hendrikto 2y ago> It all adds up to a lot to be done still, but the end result of the lazy-preemption work should be a kernel that is a bit smaller and simpler while delivering predictable latencies without the need to sprinkle scheduler-related calls throughout the code. That seems like a better solution, but getting there is going to take some time. Sounds promising. Just like EEVDF, this both simplifies and improves the status quo. Does not get better than that.
- hamilyon2 2y agoHow tight is scheduler coupled to the rest of kernel code? If one wanted to drastically simplify scheduler, for example for some scientific application which doesn't care about preemption at all, can it be done in clean, modular way? And will be any benefit?
- p_l 2y agoIf you want to run a set of processes with as little preemption as possible, for example in HPC setting, your most powerful option is to reboot the system with a selection of cores (exact amount will differ on your needs) set as isolated cpus and manually put your task there with taskset - but then you need to really manually allocate tasks to CPUs, it's trivial to end up with all tasks on wrong CPU. The standard way is to set interrupt masks so they don't go to "work" cpus and use cpusets to only allow specific cgroup to execute on given cpuset.
- kevin_thibedeau 2y agoI'd just use RT Linux. That has its own basic scheduler with the kernel scheduler running as the idle task. Real time tasks get priority over everything else.
- toast0 2y agoYou can get 95% of the way there by running a clean system with nearly no daemons, and your application setup to run with one os thread per cpu thread, with cpu pinning so they don't move. Whatever the scheduler does should be pretty low impact, because the runlist will be very short. If your application doesn't do much I/O, you won't get many interrupts either. If you can run a tickless kernel (is that still a thing, or is it normal now?), you might not get any interrupts for large periods.
- marcosdumay 2y agoLast time I looked, it was surprisingly decoupled. But the reason for drastically simplifying it would be to avoid bugs, there isn't much performance to gain compared to a well-set default one (there are plenty of settings tough). And there haven't been many bugs there. On most naive simplifications you will lose performance, not gain it. If you are running a non-interactive system, the easiest change to make is to increase the size of the process time quantum.
- AvaSayes 2y agoYeah, it’d be cool if preemption could adapt based on the event, but managing that for all events might mess with system stability. It’s like using tools like Tomba Finder for lead gen you gotta balance precision (targeted leads) with efficiency so everything runs smoothly overall.
- lincpa 2y ago[dead]