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 :-)