On 12/03/2010 11:38 AM, Chris Wright wrote:
* Srivatsa Vaddagiri (vatsa@xxxxxxxxxxxxxxxxxx) wrote:
On Fri, Dec 03, 2010 at 09:28:25AM -0800, Chris Wright wrote:
* Srivatsa Vaddagiri (vatsa@xxxxxxxxxxxxxxxxxx) wrote:
On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
Perhaps it should be a VM level option. And then invert the notion.
Create one idle domain w/out hlt trap. Give that VM a vcpu per pcpu
(pin in place probably). And have that VM do nothing other than hlt.
Then it's always runnable according to scheduler, and can "consume" the
extra work that CFS wants to give away.
That's not sufficient. Lets we have 3 guests A, B, C that need to be
rate limited to 25% on a single cpu system. We create this idle guest
D that is 100% cpu hog as per above definition. Now when one of the
guest is idle, what ensures that the idle cycles of A is given only
to D and not partly to B/C?
Yeah, I pictured priorties handling this.
All guest are of equal priorty in this case (that's how we are able to divide
time into 25% chunks), so unless we dynamically boost D's priority based on how
idle other VMs are, its not going to be easy!
Right, I think there has to be an external mgmt entity. Because num
vcpus is not static. So priorities have to be rebalanaced at vcpu
create/destroy time.
We've actually done a fair amount of testing with using priorities like
this. The granularity is extremely poor because priorities don't map
linearly to cpu time allotment. The interaction with background tasks
also gets extremely complicated.
Regards,
Anthony Liguori
thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
