From: Tim Chen <tim.c.chen@linux.intel.com>
To: Peter Zijlstra <peterz@infradead.org>, Phil Auld <pauld@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
Vineeth Remanan Pillai <vpillai@digitalocean.com>,
Nishanth Aravamudan <naravamudan@digitalocean.com>,
Julien Desfossez <jdesfossez@digitalocean.com>,
mingo@kernel.org, tglx@linutronix.de, pjt@google.com,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
subhra.mazumdar@oracle.com, fweisbec@gmail.com,
keescook@chromium.org, kerrnel@google.com,
Aaron Lu <aaron.lwe@gmail.com>,
Aubrey Li <aubrey.intel@gmail.com>,
Valentin Schneider <valentin.schneider@arm.com>,
Mel Gorman <mgorman@techsingularity.net>,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC PATCH v3 00/16] Core scheduling v3
Date: Wed, 28 Aug 2019 09:37:37 -0700 [thread overview]
Message-ID: <1a80f754-ff5b-353e-cc92-a5a4823976db@linux.intel.com> (raw)
In-Reply-To: <20190828160114.GE17205@worktop.programming.kicks-ass.net>
On 8/28/19 9:01 AM, Peter Zijlstra wrote:
> On Wed, Aug 28, 2019 at 11:30:34AM -0400, Phil Auld wrote:
>> On Tue, Aug 27, 2019 at 11:50:35PM +0200 Peter Zijlstra wrote:
>
>> The current core scheduler implementation, I believe, still has (theoretical?)
>> holes involving interrupts, once/if those are closed it may be even less
>> attractive.
>
> No; so MDS leaks anything the other sibling (currently) does, this makes
> _any_ privilidge boundary a synchronization context.
>
> Worse still, the exploit doesn't require a VM at all, any other task can
> get to it.
>
> That means you get to sync the siblings on lovely things like system
> call entry and exit, along with VMM and anything else that one would
> consider a privilidge boundary. Now, system calls are not rare, they
> are really quite common in fact. Trying to sync up siblings at the rate
> of system calls is utter madness.
>
> So under MDS, SMT is completely hosed. If you use VMs exclusively, then
> it _might_ work because a 'pure' host doesn't schedule that often
> (maybe, same assumption as for L1TF).
>
> Now, there have been proposals of moving the privilidge boundary further
> into the kernel. Just like PTI exposes the entry stack and code to
> Meltdown, the thinking is, lets expose more. By moving the priv boundary
> the hope is that we can do lots of common system calls without having to
> sync up -- lots of details are 'pending'.
>
If are willing to consider the idea that we will sync with the sibling
only if we touch potential user data, then a significant portion of
syscalls may not need to sync. Yeah, it still sucks because of the
complexity added to audit all the places in kernel that may touch
privileged data and require synchronization.
I did a prototype (without core sched), kernel build slow 2.5%.
So this use case still seem reasonable.
A worst case scenario is concurrent SMT FIO write to encrypted file,
which have a lot of synchronizations due to extended access to privilege
data by crypto, we slow by 9%.
Tim
next prev parent reply other threads:[~2019-08-28 16:37 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 20:36 [RFC PATCH v3 00/16] Core scheduling v3 Vineeth Remanan Pillai
2019-05-29 20:36 ` [RFC PATCH v3 01/16] stop_machine: Fix stop_cpus_in_progress ordering Vineeth Remanan Pillai
2019-08-08 10:54 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2019-08-26 16:19 ` [RFC PATCH v3 01/16] " mark gross
2019-08-26 16:59 ` Peter Zijlstra
2019-05-29 20:36 ` [RFC PATCH v3 02/16] sched: Fix kerneldoc comment for ia64_set_curr_task Vineeth Remanan Pillai
2019-08-08 10:55 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2019-08-26 16:20 ` [RFC PATCH v3 02/16] " mark gross
2019-05-29 20:36 ` [RFC PATCH v3 03/16] sched: Wrap rq::lock access Vineeth Remanan Pillai
2019-05-29 20:36 ` [RFC PATCH v3 04/16] sched/{rt,deadline}: Fix set_next_task vs pick_next_task Vineeth Remanan Pillai
2019-08-08 10:55 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2019-05-29 20:36 ` [RFC PATCH v3 05/16] sched: Add task_struct pointer to sched_class::set_curr_task Vineeth Remanan Pillai
2019-08-08 10:57 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2019-05-29 20:36 ` [RFC PATCH v3 06/16] sched/fair: Export newidle_balance() Vineeth Remanan Pillai
2019-08-08 10:58 ` [tip:sched/core] sched/fair: Expose newidle_balance() tip-bot for Peter Zijlstra
2019-05-29 20:36 ` [RFC PATCH v3 07/16] sched: Allow put_prev_task() to drop rq->lock Vineeth Remanan Pillai
2019-08-08 10:58 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2019-08-26 16:51 ` [RFC PATCH v3 07/16] " mark gross
2019-05-29 20:36 ` [RFC PATCH v3 08/16] sched: Rework pick_next_task() slow-path Vineeth Remanan Pillai
2019-08-08 10:59 ` [tip:sched/core] " tip-bot for Peter Zijlstra
2019-08-26 17:01 ` [RFC PATCH v3 08/16] " mark gross
2019-05-29 20:36 ` [RFC PATCH v3 09/16] sched: Introduce sched_class::pick_task() Vineeth Remanan Pillai
2019-08-26 17:14 ` mark gross
2019-05-29 20:36 ` [RFC PATCH v3 10/16] sched: Core-wide rq->lock Vineeth Remanan Pillai
2019-05-31 11:08 ` Peter Zijlstra
2019-05-31 15:23 ` Vineeth Pillai
2019-05-29 20:36 ` [RFC PATCH v3 11/16] sched: Basic tracking of matching tasks Vineeth Remanan Pillai
2019-08-26 20:59 ` mark gross
2019-05-29 20:36 ` [RFC PATCH v3 12/16] sched: A quick and dirty cgroup tagging interface Vineeth Remanan Pillai
2019-05-29 20:36 ` [RFC PATCH v3 13/16] sched: Add core wide task selection and scheduling Vineeth Remanan Pillai
2019-06-07 23:36 ` Pawan Gupta
2019-05-29 20:36 ` [RFC PATCH v3 14/16] sched/fair: Add a few assertions Vineeth Remanan Pillai
2019-05-29 20:36 ` [RFC PATCH v3 15/16] sched: Trivial forced-newidle balancer Vineeth Remanan Pillai
2019-05-29 20:36 ` [RFC PATCH v3 16/16] sched: Debug bits Vineeth Remanan Pillai
2019-05-29 21:02 ` Peter Oskolkov
2019-05-30 14:04 ` [RFC PATCH v3 00/16] Core scheduling v3 Aubrey Li
2019-05-30 14:17 ` Julien Desfossez
2019-05-31 4:55 ` Aubrey Li
2019-05-31 3:01 ` Aaron Lu
2019-05-31 5:12 ` Aubrey Li
2019-05-31 6:09 ` Aaron Lu
2019-05-31 6:53 ` Aubrey Li
2019-05-31 7:44 ` Aaron Lu
2019-05-31 8:26 ` Aubrey Li
2019-05-31 21:08 ` Julien Desfossez
2019-06-06 15:26 ` Julien Desfossez
2019-06-12 1:52 ` Li, Aubrey
2019-06-12 16:06 ` Julien Desfossez
2019-06-12 16:33 ` Julien Desfossez
2019-06-13 0:03 ` Subhra Mazumdar
2019-06-13 3:22 ` Julien Desfossez
2019-06-17 2:51 ` Aubrey Li
2019-06-19 18:33 ` Julien Desfossez
2019-07-18 10:07 ` Aaron Lu
2019-07-18 23:27 ` Tim Chen
2019-07-19 5:52 ` Aaron Lu
2019-07-19 11:48 ` Aubrey Li
2019-07-19 18:33 ` Tim Chen
2019-07-22 10:26 ` Aubrey Li
2019-07-22 10:43 ` Aaron Lu
2019-07-23 2:52 ` Aubrey Li
2019-07-25 14:30 ` Aaron Lu
2019-07-25 14:31 ` [RFC PATCH 1/3] wrapper for cfs_rq->min_vruntime Aaron Lu
2019-07-25 14:32 ` [PATCH 2/3] core vruntime comparison Aaron Lu
2019-08-06 14:17 ` Peter Zijlstra
2019-07-25 14:33 ` [PATCH 3/3] temp hack to make tick based schedule happen Aaron Lu
2019-07-25 21:42 ` [RFC PATCH v3 00/16] Core scheduling v3 Li, Aubrey
2019-07-26 15:21 ` Julien Desfossez
2019-07-26 21:29 ` Tim Chen
2019-07-31 2:42 ` Li, Aubrey
2019-08-02 15:37 ` Julien Desfossez
2019-08-05 15:55 ` Tim Chen
2019-08-06 3:24 ` Aaron Lu
2019-08-06 6:56 ` Aubrey Li
2019-08-06 7:04 ` Aaron Lu
2019-08-06 12:24 ` Vineeth Remanan Pillai
2019-08-06 13:49 ` Aaron Lu
2019-08-06 16:14 ` Vineeth Remanan Pillai
2019-08-06 14:16 ` Peter Zijlstra
2019-08-06 15:53 ` Vineeth Remanan Pillai
2019-08-06 17:03 ` Tim Chen
2019-08-06 17:12 ` Peter Zijlstra
2019-08-06 21:19 ` Tim Chen
2019-08-08 6:47 ` Aaron Lu
2019-08-08 17:27 ` Tim Chen
2019-08-08 21:42 ` Tim Chen
2019-08-10 14:15 ` Aaron Lu
2019-08-12 15:38 ` Vineeth Remanan Pillai
2019-08-13 2:24 ` Aaron Lu
2019-08-08 12:55 ` Aaron Lu
2019-08-08 16:39 ` Tim Chen
2019-08-10 14:18 ` Aaron Lu
2019-08-05 20:09 ` Phil Auld
2019-08-06 13:54 ` Aaron Lu
2019-08-06 14:17 ` Phil Auld
2019-08-06 14:41 ` Aaron Lu
2019-08-06 14:55 ` Phil Auld
2019-08-07 8:58 ` Dario Faggioli
2019-08-07 17:10 ` Tim Chen
2019-08-15 16:09 ` Dario Faggioli
2019-08-16 2:33 ` Aaron Lu
2019-09-05 1:44 ` Julien Desfossez
2019-09-06 22:17 ` Tim Chen
2019-09-18 21:27 ` Tim Chen
2019-09-06 18:30 ` Tim Chen
2019-09-11 14:02 ` Aaron Lu
2019-09-11 16:19 ` Tim Chen
2019-09-11 16:47 ` Vineeth Remanan Pillai
2019-09-12 12:35 ` Aaron Lu
2019-09-12 17:29 ` Tim Chen
2019-09-13 14:15 ` Aaron Lu
2019-09-13 17:13 ` Tim Chen
2019-09-30 11:53 ` Vineeth Remanan Pillai
2019-10-02 20:48 ` Vineeth Remanan Pillai
2019-10-10 13:54 ` Aaron Lu
2019-10-10 14:29 ` Vineeth Remanan Pillai
2019-10-11 7:33 ` Aaron Lu
2019-10-11 11:32 ` Vineeth Remanan Pillai
2019-10-11 12:01 ` Aaron Lu
2019-10-11 12:10 ` Vineeth Remanan Pillai
2019-10-12 3:55 ` Aaron Lu
2019-10-13 12:44 ` Vineeth Remanan Pillai
2019-10-14 9:57 ` Aaron Lu
2019-10-21 12:30 ` Vineeth Remanan Pillai
2019-09-12 12:04 ` Aaron Lu
2019-09-12 17:05 ` Tim Chen
2019-09-13 13:57 ` Aaron Lu
2019-09-12 23:12 ` Aubrey Li
2019-09-15 14:14 ` Aaron Lu
2019-09-18 1:33 ` Aubrey Li
2019-09-18 20:40 ` Tim Chen
2019-09-18 22:16 ` Aubrey Li
2019-09-30 14:36 ` Vineeth Remanan Pillai
2019-10-29 20:40 ` Julien Desfossez
2019-11-01 21:42 ` Tim Chen
2019-10-29 9:11 ` Dario Faggioli
2019-10-29 9:15 ` Dario Faggioli
2019-10-29 9:16 ` Dario Faggioli
2019-10-29 9:17 ` Dario Faggioli
2019-10-29 9:18 ` Dario Faggioli
2019-10-29 9:18 ` Dario Faggioli
2019-10-29 9:19 ` Dario Faggioli
2019-10-29 9:20 ` Dario Faggioli
2019-10-29 20:34 ` Julien Desfossez
2019-11-15 16:30 ` Dario Faggioli
2019-09-25 2:40 ` Aubrey Li
2019-09-25 17:24 ` Tim Chen
2019-09-25 22:07 ` Aubrey Li
2019-09-30 15:22 ` Julien Desfossez
2019-08-27 21:14 ` Matthew Garrett
2019-08-27 21:50 ` Peter Zijlstra
2019-08-28 15:30 ` Phil Auld
2019-08-28 16:01 ` Peter Zijlstra
2019-08-28 16:37 ` Tim Chen [this message]
2019-08-29 14:30 ` Phil Auld
2019-08-29 14:38 ` Peter Zijlstra
2019-09-10 14:27 ` Julien Desfossez
2019-09-18 21:12 ` Tim Chen
2019-08-28 15:59 ` Tim Chen
2019-08-28 16:16 ` Peter Zijlstra
2019-08-27 23:24 ` Aubrey Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a80f754-ff5b-353e-cc92-a5a4823976db@linux.intel.com \
--to=tim.c.chen@linux.intel.com \
--cc=aaron.lwe@gmail.com \
--cc=aubrey.intel@gmail.com \
--cc=fweisbec@gmail.com \
--cc=jdesfossez@digitalocean.com \
--cc=keescook@chromium.org \
--cc=kerrnel@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mingo@kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=naravamudan@digitalocean.com \
--cc=pauld@redhat.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=subhra.mazumdar@oracle.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=valentin.schneider@arm.com \
--cc=vpillai@digitalocean.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).