Messages in this thread | | | Date | Fri, 21 May 2021 15:33:49 +0200 | From | Peter Zijlstra <> | Subject | Re: config SCHED_CORE |
| |
On Fri, May 21, 2021 at 07:57:35AM -0400, Joel Fernandes wrote:
> > --- > > kernel/Kconfig.preempt | 14 +++++++++++++- > > 1 file changed, 13 insertions(+), 1 deletion(-) > > > > diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt > > index ea1e3331c0ba..3c4566cd20ef 100644 > > --- a/kernel/Kconfig.preempt > > +++ b/kernel/Kconfig.preempt > > @@ -104,4 +104,16 @@ config SCHED_CORE > > bool "Core Scheduling for SMT" > > default y > > depends on SCHED_SMT > > - > > + help > > + This option enables Core scheduling, a means of coordinated task > > + selection across SMT siblings with the express purpose of creating a > > + Core wide privilidge boundary. When enabled -- see prctl(PR_SCHED_CORE) > > + -- task selection will ensure all SMT siblings will execute a task > > + from the same 'core group', forcing idle when no matching task is found. > > + > > + This provides means of mitigation against a number of SMT side-channels; > > + but is, on its own, insufficient to mitigate all known side-channels. > > + Notable: the MDS class of attacks require more. > > + > > + Default enabled for anything that has SCHED_SMT, when unused there should > > + be no impact on performance. > > This description sort of makes it sound like security is the only > usecase. Perhaps we can also add here that core-scheduling can help > performance of workloads where hyperthreading is undesired, such as > when VM providers don't want to share hyperthreads. > > Thoughts?
You're right. And there's this whole class of people who want to use this to eliminate SMT interference. I'll see if I can work that in without turning the whole thing into a novella or so ;-/
| |