Re: [PATCH] kvm-vmx: add module parameter to avoid trapping HLT instructions (v2)

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/03/2010 11:38 AM, Chris Wright wrote:
> * Srivatsa Vaddagiri (vatsa@linux.vnet.ibm.com) wrote:
>    
>> On Fri, Dec 03, 2010 at 09:28:25AM -0800, Chris Wright wrote:
>>      
>>> * Srivatsa Vaddagiri (vatsa@linux.vnet.ibm.com) 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>