qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	libvir-list@redhat.com
Subject: Re: [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable kvm_pv_unhalt by default
Date: Wed, 11 Oct 2017 16:19:38 -0400	[thread overview]
Message-ID: <cdd2b3da-b243-0d17-c3b7-305532b3bc43@redhat.com> (raw)
In-Reply-To: <20171010194117.GK3246@localhost.localdomain>

On 10/10/2017 03:41 PM, Eduardo Habkost wrote:
> On Tue, Oct 10, 2017 at 02:07:25PM -0400, Waiman Long wrote:
>> On 10/10/2017 11:50 AM, Eduardo Habkost wrote:
>>>> Yes.  Another possibility is to enable it when there is >1 NUMA node in
>>>> the guest.  We generally don't do this kind of magic but higher layers
>>>> (oVirt/OpenStack) do.
>>> Can't the guest make this decision, instead of the host?
>> By guest, do you mean the guest OS itself or the admin of the guest VM?
> It could be either.  But even if action is required from the
> guest admin to get better performance in some cases, I'd argue
> that the default behavior of a Linux guest shouldn't cause a
> performance regression if the host stops hiding a feature in
> CPUID.
>
>> I am thinking about maybe adding kernel boot command line option like
>> "unfair_pvspinlock_cpu_threshold=4" which will instruct the OS to use
>> unfair spinlock if the number of CPUs is 4 or less, for example. The
>> default value of 0 will have the same behavior as it is today. Please
>> let me know what you guys think about that.
> If that's implemented, can't Linux choose a reasonable default
> for unfair_pvspinlock_cpu_threshold that won't require the admin
> to manually configure it on most cases?

It is hard to have a fixed value as it depends on the CPUs being used as
well as the kind of workloads that are being run. Besides, using unfair
locks have the undesirable side effect of being subject to lock
starvation under certain circumstances. So we may not work it to be
turned on by default. Customers have to take their own risk if they want
that.

Regards,
Longman

  reply	other threads:[~2017-10-11 20:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 21:52 [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable kvm_pv_unhalt by default Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 1/7] qemu-doc: Document minimum kernel version for KVM in x86_64 Eduardo Habkost
2017-10-09 13:40   ` Paolo Bonzini
2017-10-10 15:33     ` Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 2/7] target/i386: x86_cpu_expand_feature() helper Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 3/7] target/i386: Use global variables to control KVM defaults Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 4/7] kvm: Define KVM_FEAT_* even if CONFIG_KVM is not defined Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 5/7] target/i386: Handle kvm_auto_* compat in x86_cpu_expand_features() Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 6/7] pc: Use compat_props to control KVM defaults compatibility Eduardo Habkost
2017-10-06 21:52 ` [Qemu-devel] [PATCH 7/7] target/i386: Enable kvm_pv_unhalt by default Eduardo Habkost
2017-10-09 14:40   ` Paolo Bonzini
2017-10-09 14:43     ` Alexander Graf
2017-10-09 13:39 ` [Qemu-devel] [PATCH 0/7] x86: Rework KVM-defaults compat code, enable " Paolo Bonzini
2017-10-09 15:15   ` Waiman Long
2017-10-09 15:47     ` Paolo Bonzini
2017-10-10 15:50       ` Eduardo Habkost
2017-10-10 18:07         ` Waiman Long
2017-10-10 19:41           ` Eduardo Habkost
2017-10-11 20:19             ` Waiman Long [this message]
2017-10-13 19:01               ` Eduardo Habkost
2017-10-13 20:58                 ` Waiman Long
2017-10-13 23:56                   ` Eduardo Habkost
2017-11-07 11:21                     ` [Qemu-devel] [libvirt] " Paolo Bonzini
2017-11-08 20:07                       ` Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cdd2b3da-b243-0d17-c3b7-305532b3bc43@redhat.com \
    --to=longman@redhat.com \
    --cc=dave@stgolabs.net \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).