Messages in this thread | | | Date | Fri, 2 Nov 2018 15:13:37 -0700 | From | Nishanth Aravamudan <> | Subject | Re: [RFC 00/60] Coscheduling for Linux |
| |
On 17.09.2018 [13:33:15 +0200], Peter Zijlstra wrote: > 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 :-)
Did your approach get posted to LKML? I never saw it I don't think, and I don't see it on lore. Could it be posted as an RFC, even if not suitable for upstreaming yet, just for comparison?
Thanks! -Nish
| |