Re: VM performance issue in KVM guests.

[Avi Kivity]

On 04/15/2010 07:58 AM, Srivatsa Vaddagiri wrote:
> On Sun, Apr 11, 2010 at 11:40 PM, Avi Kivity <avi@xxxxxxxxxx 
> <mailto:avi@xxxxxxxxxx>> wrote:
>
>     The current handing of PLE is very suboptimal.  With proper
>     directed yield we should be much better there.
>
>
>
> Hi Avi,
>               By directed yield, do you mean transfer the timeslice of 
> one thread (which is contending for a lock) to another thread (which 
> is holding a lock)?

It's a priority transfer (in CFS terms, vruntime) (we don't know who 
holds the lock, so we pick a co-vcpu at random).

> If at that point in time, the lock-holder thread/VCPU is actually not 
> running currently, ie it is at the back of the runqueue, would it help 
> much? In such case, it will take time for the lock holder to run again 
> and the default timeslice it would have got could have been sufficient 
> to release the lock?

The idea is to increase the chances to the target vcpu to run, and to 
decrease the changes of the spinner to run (hopefully they change places).

> I am also working on a prototype for some other technique here - to 
> avoid preempting guest threads/VCPUs in the middle of their 
> (spin-lock) critical section. This requires guest to hint host when 
> there are in such a section. [1] has shown 33% improvement to an 
> apache benchmark based on this idea.

Certainly that has even greater potential for Linux guests.  Note that 
we spin on mutexes now, so we need to prevent preemption while the lock 
owner is running.


--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/