[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6] kvm: better MWAIT emulation for guests

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v6] kvm: better MWAIT emulation for guests
Date: Tue, 11 Apr 2017 14:43:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0

On 04/11/2017 02:41 PM, Gabriel L. Somlo wrote:
On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote:
From: "Michael S. Tsirkin" <address@hidden>

Guests that are heavy on futexes end up IPI'ing each other a lot. That
can lead to significant slowdowns and latency increase for those guests
when running within KVM.

If only a single guest is needed on a host, we have a lot of spare host
CPU time we can throw at the problem. Modern CPUs implement a feature
called "MWAIT" which allows guests to wake up sleeping remote CPUs without
an IPI - thus without an exit - at the expense of never going out of guest

The decision whether this is something sensible to use should be up to the
VM admin, so to user space. We can however allow MWAIT execution on systems
that support it properly hardware wise.

This patch adds a CAP to user space and a KVM cpuid leaf to indicate
availability of native MWAIT execution. With that enabled, the worst a
guest can do is waste as many cycles as a "jmp ." would do, so it's not
a privilege problem.
Did you mean "hlt" rather than "jmp" ?

No, hlt wouldn't waste cycles, "jmp ." does.

The point I'm trying to make here is that by removing the MWAIT trap we don't give the guest more CPU time than we would've granted it before.

We consciously do *not* expose the feature in our CPUID bitmap, as most
people will want to benefit from sleeping vCPUs to allow for over commit.

Reported-by: "Gabriel L. Somlo" <address@hidden>
That's maybe a bit inacurate, I didn't actually report anything *this*
patch is trying to address (that was rather commit 87c00572ba05aa8c9d).


Acked-by: Gabriel Somlo <address@hidden>

would be a more accurate statement instead?

Works for me :). I'm sure whoever applies this can swizzle the tag?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]