All of lore.kernel.org
 help / color / mirror / Atom feed
* config SCHED_CORE
@ 2021-05-21  3:06 Hugh Dickins
  2021-05-21  7:53 ` Peter Zijlstra
  2021-05-25  7:05 ` [PATCH] sched: Add CONFIG_SCHED_CORE help text Peter Zijlstra
  0 siblings, 2 replies; 14+ messages in thread
From: Hugh Dickins @ 2021-05-21  3:06 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: linux-kernel

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.

I decided that I probably need kernel/sched/core.o, so chose Y :)

Hugh

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21  3:06 config SCHED_CORE Hugh Dickins
@ 2021-05-21  7:53 ` Peter Zijlstra
  2021-05-21 11:18   ` Joel Fernandes
                     ` (2 more replies)
  2021-05-25  7:05 ` [PATCH] sched: Add CONFIG_SCHED_CORE help text Peter Zijlstra
  1 sibling, 3 replies; 14+ messages in thread
From: Peter Zijlstra @ 2021-05-21  7:53 UTC (permalink / raw)
  To: Hugh Dickins; +Cc: linux-kernel, joel

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/20210324214020.34142-8-joel@joelfernandes.org
)

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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21  7:53 ` Peter Zijlstra
@ 2021-05-21 11:18   ` Joel Fernandes
  2021-05-21 11:57   ` Joel Fernandes
  2021-05-21 16:09   ` Randy Dunlap
  2 siblings, 0 replies; 14+ messages in thread
From: Joel Fernandes @ 2021-05-21 11:18 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Hugh Dickins, LKML

On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <peterz@infradead.org> 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/20210324214020.34142-8-joel@joelfernandes.org
> )
>
> 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.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21  7:53 ` Peter Zijlstra
  2021-05-21 11:18   ` Joel Fernandes
@ 2021-05-21 11:57   ` Joel Fernandes
  2021-05-21 13:33     ` Peter Zijlstra
  2021-05-23 10:57     ` Peter Zijlstra
  2021-05-21 16:09   ` Randy Dunlap
  2 siblings, 2 replies; 14+ messages in thread
From: Joel Fernandes @ 2021-05-21 11:57 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Hugh Dickins, LKML

On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <peterz@infradead.org> 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/20210324214020.34142-8-joel@joelfernandes.org
> )
>
> 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?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21 11:57   ` Joel Fernandes
@ 2021-05-21 13:33     ` Peter Zijlstra
  2021-05-24 20:50       ` Joel Fernandes
  2021-05-23 10:57     ` Peter Zijlstra
  1 sibling, 1 reply; 14+ messages in thread
From: Peter Zijlstra @ 2021-05-21 13:33 UTC (permalink / raw)
  To: Joel Fernandes; +Cc: Hugh Dickins, LKML

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 ;-/

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21  7:53 ` Peter Zijlstra
  2021-05-21 11:18   ` Joel Fernandes
  2021-05-21 11:57   ` Joel Fernandes
@ 2021-05-21 16:09   ` Randy Dunlap
  2 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2021-05-21 16:09 UTC (permalink / raw)
  To: Peter Zijlstra, Hugh Dickins; +Cc: linux-kernel, joel

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/20210324214020.34142-8-joel@joelfernandes.org
> )
> 
> 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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21 11:57   ` Joel Fernandes
  2021-05-21 13:33     ` Peter Zijlstra
@ 2021-05-23 10:57     ` Peter Zijlstra
  2021-05-23 20:30       ` Hugh Dickins
  1 sibling, 1 reply; 14+ messages in thread
From: Peter Zijlstra @ 2021-05-23 10:57 UTC (permalink / raw)
  To: Joel Fernandes; +Cc: Hugh Dickins, LKML

On Fri, May 21, 2021 at 07:57:35AM -0400, Joel Fernandes wrote:
> On Fri, May 21, 2021 at 3:53 AM Peter Zijlstra <peterz@infradead.org> 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.
+
 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-23 10:57     ` Peter Zijlstra
@ 2021-05-23 20:30       ` Hugh Dickins
  2021-05-23 21:31         ` Randy Dunlap
  0 siblings, 1 reply; 14+ messages in thread
From: Hugh Dickins @ 2021-05-23 20:30 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Joel Fernandes, Hugh Dickins, Randy Dunlap, LKML

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 <peterz@infradead.org> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-23 20:30       ` Hugh Dickins
@ 2021-05-23 21:31         ` Randy Dunlap
  0 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2021-05-23 21:31 UTC (permalink / raw)
  To: Hugh Dickins, Peter Zijlstra; +Cc: Joel Fernandes, LKML

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 <peterz@infradead.org> 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


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: config SCHED_CORE
  2021-05-21 13:33     ` Peter Zijlstra
@ 2021-05-24 20:50       ` Joel Fernandes
  0 siblings, 0 replies; 14+ messages in thread
From: Joel Fernandes @ 2021-05-24 20:50 UTC (permalink / raw)
  To: Peter Zijlstra; +Cc: Hugh Dickins, LKML

On Fri, May 21, 2021 at 9:36 AM Peter Zijlstra <peterz@infradead.org> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [PATCH] sched: Add CONFIG_SCHED_CORE help text
  2021-05-21  3:06 config SCHED_CORE Hugh Dickins
  2021-05-21  7:53 ` Peter Zijlstra
@ 2021-05-25  7:05 ` Peter Zijlstra
  2021-05-25 17:24   ` Randy Dunlap
                     ` (2 more replies)
  1 sibling, 3 replies; 14+ messages in thread
From: Peter Zijlstra @ 2021-05-25  7:05 UTC (permalink / raw)
  To: Hugh Dickins
  Cc: linux-kernel, rdunlap, joel, Ingo Molnar, juri.lelli,
	vincent.guittot, dietmar.eggemann, rostedt, bsegall, mgorman,
	bristot, Valentin Schneider

Subject: sched: Add CONFIG_SCHED_CORE help text
From: Peter Zijlstra <peterz@infradead.org>
Date: Tue May 25 08:53:28 CEST 2021

Hugh noted that the SCHED_CORE Kconfig option could do with a help
text.

Requested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
 kernel/Kconfig.preempt |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

--- 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 permits Core Scheduling, a means of coordinated task
+	  selection across SMT siblings. When enabled -- see
+	  prctl(PR_SCHED_CORE) -- task selection ensures that 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.
+
+	  SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
+	  unused there should be no impact on performance.
+
 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] sched: Add CONFIG_SCHED_CORE help text
  2021-05-25  7:05 ` [PATCH] sched: Add CONFIG_SCHED_CORE help text Peter Zijlstra
@ 2021-05-25 17:24   ` Randy Dunlap
  2021-05-25 22:17   ` Hugh Dickins
  2021-06-01 14:04   ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
  2 siblings, 0 replies; 14+ messages in thread
From: Randy Dunlap @ 2021-05-25 17:24 UTC (permalink / raw)
  To: Peter Zijlstra, Hugh Dickins
  Cc: linux-kernel, joel, Ingo Molnar, juri.lelli, vincent.guittot,
	dietmar.eggemann, rostedt, bsegall, mgorman, bristot,
	Valentin Schneider

On 5/25/21 12:05 AM, Peter Zijlstra wrote:
> Subject: sched: Add CONFIG_SCHED_CORE help text
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Tue May 25 08:53:28 CEST 2021
> 
> Hugh noted that the SCHED_CORE Kconfig option could do with a help
> text.
> 
> Requested-by: Hugh Dickins <hughd@google.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>

Thanks.

> ---
>  kernel/Kconfig.preempt |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> --- 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 permits Core Scheduling, a means of coordinated task
> +	  selection across SMT siblings. When enabled -- see
> +	  prctl(PR_SCHED_CORE) -- task selection ensures that 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.
> +
> +	  SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
> +	  unused there should be no impact on performance.
> +
>  
> 


-- 
~Randy


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] sched: Add CONFIG_SCHED_CORE help text
  2021-05-25  7:05 ` [PATCH] sched: Add CONFIG_SCHED_CORE help text Peter Zijlstra
  2021-05-25 17:24   ` Randy Dunlap
@ 2021-05-25 22:17   ` Hugh Dickins
  2021-06-01 14:04   ` [tip: sched/core] " tip-bot2 for Peter Zijlstra
  2 siblings, 0 replies; 14+ messages in thread
From: Hugh Dickins @ 2021-05-25 22:17 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Hugh Dickins, linux-kernel, rdunlap, joel, Ingo Molnar,
	juri.lelli, vincent.guittot, dietmar.eggemann, rostedt, bsegall,
	mgorman, bristot, Valentin Schneider

On Tue, 25 May 2021, Peter Zijlstra wrote:

> Subject: sched: Add CONFIG_SCHED_CORE help text
> From: Peter Zijlstra <peterz@infradead.org>
> Date: Tue May 25 08:53:28 CEST 2021
> 
> Hugh noted that the SCHED_CORE Kconfig option could do with a help
> text.
> 
> Requested-by: Hugh Dickins <hughd@google.com>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Thanks,
Acked-by: Hugh Dickins <hughd@google.com>
if necessary (but there's more than enough of me there already).

> ---
>  kernel/Kconfig.preempt |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> --- 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 permits Core Scheduling, a means of coordinated task
> +	  selection across SMT siblings. When enabled -- see
> +	  prctl(PR_SCHED_CORE) -- task selection ensures that 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.
> +
> +	  SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
> +	  unused there should be no impact on performance.
> +

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [tip: sched/core] sched: Add CONFIG_SCHED_CORE help text
  2021-05-25  7:05 ` [PATCH] sched: Add CONFIG_SCHED_CORE help text Peter Zijlstra
  2021-05-25 17:24   ` Randy Dunlap
  2021-05-25 22:17   ` Hugh Dickins
@ 2021-06-01 14:04   ` tip-bot2 for Peter Zijlstra
  2 siblings, 0 replies; 14+ messages in thread
From: tip-bot2 for Peter Zijlstra @ 2021-06-01 14:04 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Peter Zijlstra (Intel), Randy Dunlap, Hugh Dickins, x86, linux-kernel

The following commit has been merged into the sched/core branch of tip:

Commit-ID:     7b419f47facd286c6723daca6ad69ec355473f78
Gitweb:        https://git.kernel.org/tip/7b419f47facd286c6723daca6ad69ec355473f78
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Tue, 25 May 2021 08:53:28 +02:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Tue, 01 Jun 2021 16:00:10 +02:00

sched: Add CONFIG_SCHED_CORE help text

Hugh noted that the SCHED_CORE Kconfig option could do with a help
text.

Requested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Hugh Dickins <hughd@google.com>
Link: https://lkml.kernel.org/r/YKyhtwhEgvtUDOyl@hirez.programming.kicks-ass.net
---
 kernel/Kconfig.preempt | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index ea1e333..bd7c414 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 permits Core Scheduling, a means of coordinated task
+	  selection across SMT siblings. When enabled -- see
+	  prctl(PR_SCHED_CORE) -- task selection ensures that 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.
+
+	  SCHED_CORE is default enabled when SCHED_SMT is enabled -- when
+	  unused there should be no impact on performance.
+
 

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-06-01 14:05 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-21  3:06 config SCHED_CORE Hugh Dickins
2021-05-21  7:53 ` Peter Zijlstra
2021-05-21 11:18   ` Joel Fernandes
2021-05-21 11:57   ` Joel Fernandes
2021-05-21 13:33     ` Peter Zijlstra
2021-05-24 20:50       ` Joel Fernandes
2021-05-23 10:57     ` Peter Zijlstra
2021-05-23 20:30       ` Hugh Dickins
2021-05-23 21:31         ` Randy Dunlap
2021-05-21 16:09   ` Randy Dunlap
2021-05-25  7:05 ` [PATCH] sched: Add CONFIG_SCHED_CORE help text Peter Zijlstra
2021-05-25 17:24   ` Randy Dunlap
2021-05-25 22:17   ` Hugh Dickins
2021-06-01 14:04   ` [tip: sched/core] " tip-bot2 for Peter Zijlstra

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.