Re: [RFC PATCH 0/4] Shared vhost design

Eyal Moscovici [off-list ref] writes:
...

We can start to implement polling, but I am unsure if the cgroups 
integration 
will be sufficient. The polling vhost thread should be scheduled all
the time and just moving it from one cgroup to the other wont be 
sufficient. 
I think it needs a deeper integration to the point where either we have a 
vhost thread for each cgroup or the vhost thread enforces the cgroup 
policies over its polled VM guests.

Agreed, what we have with cgroups is not sufficient. I am waiting
for Tejun et al to comment on our approach :) Michael mentioned whether
it's possible to integrate cgroups into workgroups which I think is a more
generic and the preferred solution. I just don't know yet how easy/difficult
it is to implement this with the new cgroups unified hierarchy.


BTW, I am working on the numbers you had asked for. Honestly, I think the
cost of cgroups could be similar to running a vhost thread/guest since
that is how cgroups integration currently works. But it's good to have the
numbers before us. 

quoted

So simple polling by vhost is kind of ok for some guests, but I think to
really make it work for a reasonably wide selection of guests/workloads
you need to combine it with 1. polling the NIC - it makes no sense to me
to only poll one side of the equation; and probably 2. - polling in
guest.

I agree that we need polling on the NIC which could probably be achieved 
by using
the polling interface introduced in kernel 3.11: 
http://lwn.net/Articles/551284/
although I never tried using it myself.
About your point about polling inside the guest, I think it is orthogonal 
to polling
in the host.


Eyal Moscovici
HL-Cloud Infrastructure Solutions
IBM Haifa Research Lab