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

[Anthony Liguori <anthony@codemonkey.ws>]

On 12/02/2010 02:40 PM, Marcelo Tosatti wrote:
> On Thu, Dec 02, 2010 at 11:14:16AM -0800, Chris Wright wrote:
>    
>> * Anthony Liguori (aliguori@us.ibm.com) wrote:
>>      
>>> In certain use-cases, we want to allocate guests fixed time slices where idle
>>> guest cycles leave the machine idling.  There are many approaches to achieve
>>> this but the most direct is to simply avoid trapping the HLT instruction which
>>> lets the guest directly execute the instruction putting the processor to sleep.
>>>        
>> I like the idea, esp to keep from burning power.
>>
>>      
>>> Introduce this as a module-level option for kvm-vmx.ko since if you do this
>>> for one guest, you probably want to do it for all.  A similar option is possible
>>> for AMD but I don't have easy access to AMD test hardware.
>>>        
>> 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.
>>
>> What do you think?
>>
>> thanks,
>> -chris
>>      
> Consuming the timeslice outside guest mode is less intrusive and easier
> to replace. Something like this should work?
>
> if (vcpu->arch.mp_state == KVM_MP_STATE_HALTED) {
>      while (!need_resched())
>          default_idle();
> }
>    

This looked nice but the implementation in practice wasn't unless I 
totally misunderstood what you were getting at.

default_idle() is not exported to modules and is not an interface meant 
to be called directly.  Plus, an idle loop like this delays the guest 
until the scheduler wants to run something else but it doesn't account 
for another thread trying to inject an event into the halting thread.  
It's not immediately clear to me how to have what's effectively a wait 
queue that hlts instead of calls the scheduler.  You could mess around 
with various signalling mechanisms but it gets ugly fast.

So I circled back to disabling hlt exiting this time taking care of 
updating GUEST_ACTIVITY_STATE when necessary.

Regards,

Anthony Liguori

> But you agree this is no KVM business.
>
> --
> 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
>