Linux Will Keep Core Scheduling Disabled By Default
Among the many new features that were sent in so far this week for the Linux 5.14 merge window was the long in-development work on "core scheduling" to reduce the Hyper Threading information leakage risks from side channels and help ensuring deterministic performance on such HT/SMT systems by controlling the resources that can run on a sibling thread. As a follow-up to that article from a few days ago, core scheduling will now be disabled by default.
With the original scheduling pull request that landed earlier this week, the new "CONFIG_SCHED_CORE" build option defaulted to on by default. Linus Torvalds noticed that default enabling even though core scheduling is unlikely to be of interest to the vast majority of Linux users.
The Linux creator commented, "I see no reason why anybody would enable it outside of cloud providers, which doesn't argue for it being on by default."
Apparently that default "Y" (yes) enabling was an oversight that is now fixed in the newer Linux 5.14 upstream code.
When the core scheduling (SCHED_CORE) code is built into the kernel, it doesn't impose any new restrictions or changes out-of-the-box and should have "no measurable impact on performance". It's only when making use of the new prctl() options around core scheduling groups to coordinate scheduling across SMT siblings are there any changes in behavior (and performance).
Again though the primary driver for core scheduling are the big cloud providers in wanting to try to ensure SMT/HT is safe given the vulnerabilities in recent years and not wanting to have to disable it due to then seeing a sharp drop in their virtual CPU "vCPU" count they can offer to customers on a per server basis. For those not running a mix of trusted/untrusted workloads on your systems, core scheduling won't be of much use.
With the original scheduling pull request that landed earlier this week, the new "CONFIG_SCHED_CORE" build option defaulted to on by default. Linus Torvalds noticed that default enabling even though core scheduling is unlikely to be of interest to the vast majority of Linux users.
The Linux creator commented, "I see no reason why anybody would enable it outside of cloud providers, which doesn't argue for it being on by default."
Apparently that default "Y" (yes) enabling was an oversight that is now fixed in the newer Linux 5.14 upstream code.
When the core scheduling (SCHED_CORE) code is built into the kernel, it doesn't impose any new restrictions or changes out-of-the-box and should have "no measurable impact on performance". It's only when making use of the new prctl() options around core scheduling groups to coordinate scheduling across SMT siblings are there any changes in behavior (and performance).
Again though the primary driver for core scheduling are the big cloud providers in wanting to try to ensure SMT/HT is safe given the vulnerabilities in recent years and not wanting to have to disable it due to then seeing a sharp drop in their virtual CPU "vCPU" count they can offer to customers on a per server basis. For those not running a mix of trusted/untrusted workloads on your systems, core scheduling won't be of much use.
9 Comments