On Thu, May 20, 2021 at 08:06:07PM -0700, Hugh Dickins wrote:
> Hi Peter,
>
> make oldconfig gave me no help at all on how to decide whether to choose
> SCHED_CORE Y or n, beyond it recommending Y. Maybe you'll delete that
> option later, or maybe removing the prompt string would silence it.
Ah, you're quite right. I never seem to have gotten around to actually
writing anything useful there :/ Similarly the documentation for all
this seems to have gone missing too.
Joel, could I ask you to refresh the document to match the current state
of things and repost? I still whole hartedly despise this RST crud, it
makes it so hard to read / modify the files.
( I think the latest version is here:
https://lkml.kernel.org/r/[email protected]
)
Anyway, how is something like the below, Joel can add a reference to the
document once it's there.
---
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.
On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <[email protected]> wrote:
>
> On Thu, May 20, 2021 at 08:06:07PM -0700, Hugh Dickins wrote:
> > Hi Peter,
> >
> > make oldconfig gave me no help at all on how to decide whether to choose
> > SCHED_CORE Y or n, beyond it recommending Y. Maybe you'll delete that
> > option later, or maybe removing the prompt string would silence it.
>
> Ah, you're quite right. I never seem to have gotten around to actually
> writing anything useful there :/ Similarly the documentation for all
> this seems to have gone missing too.
>
> Joel, could I ask you to refresh the document to match the current state
> of things and repost? I still whole hartedly despise this RST crud, it
> makes it so hard to read / modify the files.
>
> ( I think the latest version is here:
> https://lkml.kernel.org/r/[email protected]
> )
>
> Anyway, how is something like the below, Joel can add a reference to the
> document once it's there.
Sure thing, Peter! I will work on it and post a patch.
- Joel
>
> ---
> 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.
On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <[email protected]> wrote:
>
> On Thu, May 20, 2021 at 08:06:07PM -0700, Hugh Dickins wrote:
> > Hi Peter,
> >
> > make oldconfig gave me no help at all on how to decide whether to choose
> > SCHED_CORE Y or n, beyond it recommending Y. Maybe you'll delete that
> > option later, or maybe removing the prompt string would silence it.
>
> Ah, you're quite right. I never seem to have gotten around to actually
> writing anything useful there :/ Similarly the documentation for all
> this seems to have gone missing too.
>
> Joel, could I ask you to refresh the document to match the current state
> of things and repost? I still whole hartedly despise this RST crud, it
> makes it so hard to read / modify the files.
>
> ( I think the latest version is here:
> https://lkml.kernel.org/r/[email protected]
> )
>
> Anyway, how is something like the below, Joel can add a reference to the
> document once it's there.
>
> ---
> 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?
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 ;-/
On 5/21/21 12:53 AM, Peter Zijlstra wrote:
> On Thu, May 20, 2021 at 08:06:07PM -0700, Hugh Dickins wrote:
>> Hi Peter,
>>
>> make oldconfig gave me no help at all on how to decide whether to choose
>> SCHED_CORE Y or n, beyond it recommending Y. Maybe you'll delete that
>> option later, or maybe removing the prompt string would silence it.
>
> Ah, you're quite right. I never seem to have gotten around to actually
> writing anything useful there :/ Similarly the documentation for all
> this seems to have gone missing too.
>
> Joel, could I ask you to refresh the document to match the current state
> of things and repost? I still whole hartedly despise this RST crud, it
> makes it so hard to read / modify the files.
>
> ( I think the latest version is here:
> https://lkml.kernel.org/r/[email protected]
> )
>
> Anyway, how is something like the below, Joel can add a reference to the
> document once it's there.
>
> ---
> 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)
privilege
while you are at it.
> + -- 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.
>
--
~Randy
On Fri, May 21, 2021 at 07:57:35AM -0400, Joel Fernandes wrote:
> On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <[email protected]> wrote:
> > + 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.
Something like so then?
---
kernel/Kconfig.preempt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index ea1e3331c0ba..cd497fecfd43 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -104,4 +104,18 @@ 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. 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.
+
+ Use of this feature includes:
+ - mitigation of some (not all) SMT side channels;
+ - limiting SMT interference to improve determinism and/or performance.
+
+ Default enabled for anything that has SCHED_SMT, when unused there
+ should be no impact on performance.
+
On Sun, 23 May 2021, Peter Zijlstra wrote:
> On Fri, May 21, 2021 at 07:57:35AM -0400, Joel Fernandes wrote:
> > On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <[email protected]> wrote:
> > > + 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.
>
> Something like so then?
Much more helpful, thanks. And I agree that you have to keep it fairly
brief here: I think you've struck the right balance. Some nits below.
>
> ---
> kernel/Kconfig.preempt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
> index ea1e3331c0ba..cd497fecfd43 100644
> --- a/kernel/Kconfig.preempt
> +++ b/kernel/Kconfig.preempt
> @@ -104,4 +104,18 @@ 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
Maybe s/scheduling/Scheduling/ to match the title?
I think I got the picture once I reached the end, but was confused here
by the stages of enablement. s/This option enables/This option permits/
would be clearer, I think.
> + selection across SMT siblings. When enabled -- see
> + prctl(PR_SCHED_CORE) -- task selection will ensure all SMT siblings
s/will ensure/ensures that/ (it felt like too many "will"s before)
> + will execute a task from the same 'core group', forcing idle when no
> + matching task is found.
> +
> + Use of this feature includes:
> + - mitigation of some (not all) SMT side channels;
> + - limiting SMT interference to improve determinism and/or performance.
> +
> + Default enabled for anything that has SCHED_SMT, when unused there
"SCHED_CORE is default enabled when SCHED_SMT is enabled - when unused there"
would be better.
> + should be no impact on performance.
> +
Thanks,
Hugh
On 5/23/21 1:30 PM, Hugh Dickins wrote:
> On Sun, 23 May 2021, Peter Zijlstra wrote:
>> On Fri, May 21, 2021 at 07:57:35AM -0400, Joel Fernandes wrote:
>>> On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <[email protected]> wrote:
>>>> + 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.
>>
>> Something like so then?
>
> Much more helpful, thanks. And I agree that you have to keep it fairly
> brief here: I think you've struck the right balance. Some nits below.
>
>>
>> ---
>> kernel/Kconfig.preempt | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
>> index ea1e3331c0ba..cd497fecfd43 100644
>> --- a/kernel/Kconfig.preempt
>> +++ b/kernel/Kconfig.preempt
>> @@ -104,4 +104,18 @@ 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
>
> Maybe s/scheduling/Scheduling/ to match the title?
>
> I think I got the picture once I reached the end, but was confused here
> by the stages of enablement. s/This option enables/This option permits/
> would be clearer, I think.
>
I like all of Hugh's suggestions...
>
>> + selection across SMT siblings. When enabled -- see
>> + prctl(PR_SCHED_CORE) -- task selection will ensure all SMT siblings
>
> s/will ensure/ensures that/ (it felt like too many "will"s before)
especially that one. ^^^
>> + will execute a task from the same 'core group', forcing idle when no
>> + matching task is found.
>> +
>> + Use of this feature includes:
>> + - mitigation of some (not all) SMT side channels;
>> + - limiting SMT interference to improve determinism and/or performance.
>> +
>> + Default enabled for anything that has SCHED_SMT, when unused there
>
> "SCHED_CORE is default enabled when SCHED_SMT is enabled - when unused there"
> would be better.
>
>> + should be no impact on performance.
thanks.
--
~Randy
On Fri, May 21, 2021 at 9:36 AM Peter Zijlstra <[email protected]> wrote:
>
> 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.
That's good, even more core scheduling users ;-)
> I'll see if I can work that in
> without turning the whole thing into a novella or so ;-/
Your patch looked good to me (delta Randy/Hugh's comments). I still
owe you the documentation patch refresh, I'll send it out soon.
Thanks,
- Joel