| Subject | Re: [RFC 00/60] Coscheduling for Linux | From | Subhra Mazumdar <> | Date | Fri, 26 Oct 2018 16:05:10 -0700 |
| |
> 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. > The leader doesn't kick the other cpus _immediately_ to switch to a different cosched group. So threads from previous cosched group will keep running in other HTs till their sched_slice is over (in worst case). This can still keep the window of L1TF vulnerability open?
|