28cb1ec5cb
Aggressively try to keep tasks running on the same CPU / cache / domain, to achieve higher performance when the system is not over commissioned. This is done by giving a second chance in ops.enqueue(), in addition to ops.select_cpu(), to find an idle CPU close to the previously used CPU. Moreover, even if the task is dispatched to the global DSQs, always try to check if there is an idle CPU in the primary domain that can immediately consume the task. = Results = This change seems to provide a minor, but consistent, boost of performance with the CPU-intensive benchmarks from the CachyOS benchmarks selection [1]. Similar results can also be noticed with some WebGL benchmarks [2], when system usage is close to its maximum capacity. Test: - cachyos-benchmarker System: - AMD Ryzen 7 5800X 8-Core Processor Metrics: - total time: elapsed time of all benchmarks - total score: geometric mean of all benchmarks NOTE: total time is the most relevant, since it gives a measure of the aggregate performance, while the total score emphasizes more on performance consistency across all benchmarks. == Results: summary == +-------------------------+---------------------+---------------------+ | Scheduler | Total Time | Total Score | | | (less = better) | (less = better) | +-------------------------+---------------------+---------------------+ | EEVDF | 624.44 sec | 123.68 | | bpfland | 625.34 sec | 122.21 | | bpfland-task-affinity | 623.67 sec | 122.27 | +-------------------------+---------------------+---------------------+ == Conclusion == With this patch applied, bpfland shows both a better performance and consistency. Although the gains are small (less than 1%), they are still significant for this type of benchmark and consistently appear across multiple runs. [1] https://github.com/CachyOS/cachyos-benchmarker [2] https://webglsamples.org/aquarium/aquarium.html Tested-by: Piotr Gorski < piotr.gorski@cachyos.org > Signed-off-by: Andrea Righi <andrea.righi@linux.dev> |
||
|---|---|---|
| .. | ||
| c | ||
| include | ||
| rust | ||
| meson.build | ||
| README.md | ||
| sync-to-kernel.sh | ||
SCHED_EXT SCHEDULERS
Introduction
This directory contains the repo's schedulers.
Some of these schedulers are simply examples of different types of schedulers that can be built using sched_ext. They can be loaded and used to schedule on your system, but their primary purpose is to illustrate how various features of sched_ext can be used.
Other schedulers are actually performant, production-ready schedulers. That is, for the correct workload and with the correct tuning, they may be deployed in a production environment with acceptable or possibly even improved performance. Some of the examples could be improved to become production schedulers.
Please see the following README files for details on each of the various types of schedulers:
- rust describes all of the schedulers with rust user space components. All of these schedulers are production ready.
- c describes all of the schedulers with C user space components. All of these schedulers are production ready.
Note on syncing
Note that there is a sync-to-kernel.sh script in this directory. This is used to sync any changes to the specific schedulers with the Linux kernel tree. If you've made any changes to a scheduler in please use the script to synchronize with the sched_ext Linux kernel tree:
$ ./sync-to-kernel.sh /path/to/kernel/tree