Messages in this thread | | | Date | Mon, 17 Sep 2018 14:25:38 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC 00/60] Coscheduling for Linux |
| |
On Fri, Sep 14, 2018 at 06:25:44PM +0200, Jan H. Schönherr wrote:
> Assuming, there is a cgroup-less solution that can prevent simultaneous > execution of tasks on a core, when they're not supposed to. How would you > tell the scheduler, which tasks these are?
Specifically for L1TF I hooked into/extended KVM's preempt_notifier registration interface, which tells us which tasks are VCPUs and to which VM they belong.
But if we want to actually expose this to userspace, we can either do a prctl() or extend struct sched_attr.
> >> 1. Execute parallel applications that rely on active waiting or synchronous > >> execution concurrently with other applications. > >> > >> The prime example in this class are probably virtual machines. Here, > >> coscheduling is an alternative to paravirtualized spinlocks, pause loop > >> exiting, and other techniques with its own set of advantages and > >> disadvantages over the other approaches. > > > > Note that in order to avoid PLE and paravirt spinlocks and paravirt > > tlb-invalidate you have to gang-schedule the _entire_ VM, not just SMT > > siblings. > > > > Now explain to me how you're going to gang-schedule a VM with a good > > number of vCPU threads (say spanning a number of nodes) and preserving > > the rest of CFS without it turning into a massive trainwreck? > > You probably don't -- for the same reason, why it is a bad idea to give > an endless loop realtime priority. It's just a bad idea. As I said in the > text you quoted: coscheduling comes with its own set of advantages and > disadvantages. Just because you find one example, where it is a bad idea, > doesn't make it a bad thing in general.
Well, you mentioned it as an alternative to paravirt spinlocks -- I'm saying that co-scheduling cannot do that, you need full featured gang-scheduling for that.
| |