On 21/04/2017 12:05, Alexander Graf wrote:
>
>
> On 21.04.17 12:02, Paolo Bonzini wrote:
>>
>>
>> On 12/04/2017 18:29, Michael S. Tsirkin wrote:
>>> I don't really agree we do not need the PV flag. mwait on kvm is
>>> different from mwait on bare metal in that you are heavily penalized by
>>> s
On 21.04.17 12:02, Paolo Bonzini wrote:
On 12/04/2017 18:29, Michael S. Tsirkin wrote:
I don't really agree we do not need the PV flag. mwait on kvm is
different from mwait on bare metal in that you are heavily penalized by
scheduler for polling unless you configure the host just so.
HLT let
On 12/04/2017 18:29, Michael S. Tsirkin wrote:
> I don't really agree we do not need the PV flag. mwait on kvm is
> different from mwait on bare metal in that you are heavily penalized by
> scheduler for polling unless you configure the host just so.
> HLT lets you give up the host CPU if you kno
On Wed, Apr 12, 2017 at 04:54:10PM +0200, Alexander Graf wrote:
>
>
> On 12.04.17 16:34, Jim Mattson wrote:
> > Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
> > monitor and mwait instructions as nop"), so when we intercept
> > MONITOR/MWAIT, we synthesize #UD. Perhaps it
On Wed, Apr 12, 2017 at 7:54 AM, Alexander Graf wrote:
>
>
> On 12.04.17 16:34, Jim Mattson wrote:
>>
>> Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
>> monitor and mwait instructions as nop"), so when we intercept
>> MONITOR/MWAIT, we synthesize #UD. Perhaps it is this d
On 12.04.17 16:34, Jim Mattson wrote:
Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
monitor and mwait instructions as nop"), so when we intercept
MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from
vanilla kvm that motivates the following idea...
So y
Actually, we have rejected commit 87c00572ba05aa8c ("kvm: x86: emulate
monitor and mwait instructions as nop"), so when we intercept
MONITOR/MWAIT, we synthesize #UD. Perhaps it is this difference from
vanilla kvm that motivates the following idea...
Since we're still not going to report MONITOR s
> Am 11.04.2017 um 19:10 schrieb Jim Mattson :
>
> This might be more useful if it could be dynamically toggled on and
> off, depending on system load.
What would trapping mwait (currently) buy you?
As it stands today, before this patch, mwait is simply implemented as a nop, so
enabling the t
This might be more useful if it could be dynamically toggled on and
off, depending on system load.
On Tue, Apr 11, 2017 at 4:45 AM, Alexander Graf wrote:
> From: "Michael S. Tsirkin"
>
> Guests that are heavy on futexes end up IPI'ing each other a lot. That
> can lead to significant slowdowns an
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"
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
On Tue, Apr 11, 2017 at 08:41:11AM -0400, Gabriel L. Somlo wrote:
> On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote:
> > From: "Michael S. Tsirkin"
> >
> > Guests that are heavy on futexes end up IPI'ing each other a lot. That
> > can lead to significant slowdowns and latency incre
On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote:
> From: "Michael S. Tsirkin"
>
> 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
From: "Michael S. Tsirkin"
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
13 matches
Mail list logo
