Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 17 Sep 2018 13:33:15 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Jan =?iso-8859-1?Q?H=2E_Sch=F6nherr?= <jschoenh@amazon.de>
Cc:     Ingo Molnar <mingo@redhat.com>, linux-kernel@vger.kernel.org,
        Paul Turner <pjt@google.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Morten Rasmussen <morten.rasmussen@arm.com>,
        Tim Chen <tim.c.chen@linux.intel.com>
Subject: Re: [RFC 00/60] Coscheduling for Linux
Message-ID: <20180917113315.GS24124@hirez.programming.kicks-ass.net>
References: <20180907214047.26914-1-jschoenh@amazon.de>
 <20180914111251.GC24106@hirez.programming.kicks-ass.net>
 <1d86f497-9fef-0b19-50d6-d46ef1c0bffa@amazon.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1d86f497-9fef-0b19-50d6-d46ef1c0bffa@amazon.de>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Sch?nherr wrote:
> On 09/14/2018 01:12 PM, Peter Zijlstra wrote:
> > On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Sch?nherr wrote:

> >> B) Why would I want this?
> > 
> >>    In the L1TF context, it prevents other applications from loading
> >>    additional data into the L1 cache, while one application tries to leak
> >>    data.
> > 
> > That is the whole and only reason you did this;
> It really isn't. But as your mind seems made up, I'm not going to bother
> to argue.

> >> D) What can I *not* do with this?
> >> ---------------------------------
> >>
> >> Besides the missing load-balancing within coscheduled task-groups, this
> >> implementation has the following properties, which might be considered
> >> short-comings.
> >>
> >> This particular implementation focuses on SCHED_OTHER tasks managed by CFS
> >> and allows coscheduling them. Interrupts as well as tasks in higher
> >> scheduling classes are currently out-of-scope: they are assumed to be
> >> negligible interruptions as far as coscheduling is concerned and they do
> >> *not* cause a preemption of a whole group. This implementation could be
> >> extended to cover higher scheduling classes. Interrupts, however, are an
> >> orthogonal issue.
> >>
> >> The collective context switch from one coscheduled set of tasks to another
> >> -- while fast -- is not atomic. If a use-case needs the absolute guarantee
> >> that all tasks of the previous set have stopped executing before any task
> >> of the next set starts executing, an additional hand-shake/barrier needs to
> >> be added.
> > 
> > IOW it's completely friggin useless for L1TF.
> 
> Do you believe me now, that L1TF is not "the whole and only reason" I did this? :D

You did mention this work first to me in the context of L1TF, so I might
have jumped to conclusions here.

Also, I have, of course, been looking at (SMT) co-scheduling,
specifically in the context of L1TF, myself. I came up with a vastly
different approach. Tim - where are we on getting some of that posted?

Note; that even though I wrote much of that code, I don't particularly
like it either :-)