Re: [PATCH] [RESEND] KVM:VMX: Add support for Pause-Loop Exiting

[Avi Kivity <avi@redhat.com>]

On 09/27/2009 04:07 PM, Joerg Roedel wrote:
> On Sun, Sep 27, 2009 at 03:47:55PM +0200, Avi Kivity wrote:
>    
>> On 09/27/2009 03:46 PM, Joerg Roedel wrote:
>>      
>>>        
>>>> We can't find exactly which vcpu, but we can:
>>>>
>>>> - rule out threads that are not vcpus for this guest
>>>> - rule out threads that are already running
>>>>
>>>> A major problem with sleep() is that it effectively reduces the vm
>>>> priority relative to guests that don't have spinlock contention.  By
>>>> selecting a random nonrunnable vcpu belonging to this guest, we at least
>>>> preserve the guest's timeslice.
>>>>
>>>>          
>>> Ok, that makes sense. But before trying that we should probably try to
>>> call just yield() instead of schedule()? I remember someone from our
>>> team here at AMD did this for Xen a while ago and already had pretty
>>> good results with that. Xen has a completly other scheduler but maybe
>>> its worth trying?
>>>
>>>        
>> yield() is a no-op in CFS.
>>      
> Hmm, true. At least when kernel.sched_compat_yield == 0, which it is on my
> distro.
> If the scheduler would give us something like a real_yield() function
> which asumes kernel.sched_compat_yield = 1 might help. At least its
> better than sleeping for some random amount of time.
>
>    

Depends.  If it's a global yield(), yes.  If it's a local yield() that 
doesn't rebalance the runqueues we might be left with the spinning task 
re-running.

Also, if yield means "give up the reminder of our timeslice", then we 
potentially end up sleeping a much longer random amount of time.  If we 
yield to another vcpu in the same guest we might not care, but if we 
yield to some other guest we're seriously penalizing ourselves.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.