From: Waiman Long <longman@redhat.com>
To: Davidlohr Bueso <dave@stgolabs.net>, Wanpeng Li <kernellwp@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Radim Krcmar <rkrcmar@redhat.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Juergen Gross <jgross@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
the arch/x86 maintainers <x86@kernel.org>,
xen-devel <xen-devel@lists.xenproject.org>,
LKML <linux-kernel@vger.kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU
Date: Mon, 23 Jul 2018 09:52:52 -0400 [thread overview]
Message-ID: <434efa92-844d-46d0-65c4-86eb6365f024@redhat.com> (raw)
In-Reply-To: <20180723044257.m7pjrnp7jjqggqij@linux-r8p5>
On 07/23/2018 12:42 AM, Davidlohr Bueso wrote:
> On Mon, 23 Jul 2018, Wanpeng Li wrote:
>
>> On Fri, 20 Jul 2018 at 06:03, Waiman Long <longman@redhat.com> wrote:
>>>
>>> On 07/19/2018 05:54 PM, Davidlohr Bueso wrote:
>>> > On Thu, 19 Jul 2018, Waiman Long wrote:
>>> >
>>> >> On a VM with only 1 vCPU, the locking fast paths will always be
>>> >> successful. In this case, there is no need to use the the PV
>>> qspinlock
>>> >> code which has higher overhead on the unlock side than the native
>>> >> qspinlock code.
>>> >>
>>> >> The xen_pvspin veriable is also turned off in this 1 vCPU case to
>
> s/veriable
> variable
>
>>> >> eliminate unneeded pvqspinlock initialization in xen_init_lock_cpu()
>>> >> which is run after xen_init_spinlocks().
>>> >
>>> > Wouldn't kvm also want this?
>>> >
>>> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>>> > index a37bda38d205..95aceb692010 100644
>>> > --- a/arch/x86/kernel/kvm.c
>>> > +++ b/arch/x86/kernel/kvm.c
>>> > @@ -457,7 +457,8 @@ static void __init sev_map_percpu_data(void)
>>> > static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
>>> > {
>>> > native_smp_prepare_cpus(max_cpus);
>>> > - if (kvm_para_has_hint(KVM_HINTS_REALTIME))
>>> > + if (num_possible_cpus() == 1 ||
>>> > + kvm_para_has_hint(KVM_HINTS_REALTIME))
>>> > static_branch_disable(&virt_spin_lock_key);
>>> > }
>>>
>>> That doesn't really matter as the slowpath will never get executed in
>>> the 1 vCPU case.
>
> How does this differ then from xen, then? I mean, same principle applies.
I am not saying this patch is wrong. I am just saying that this is not
necessary.
In the xen case, they have a single variable that controls if
pvqspinlock should be used and turn off all the knobs accordingly. There
is no such equivalent in kvm. We had talked about that in the past, but
didn't come to a conclusion. In the 1 vCPU case, the most important
thing is to not use the pvqspinlock unlock path which add unneeded
runtime overhead.
The others just have a slight boot time overhead. For me, they are
optional. So I don't bother to add code to explicit turn them off as the
result will be the same with or without them.
>
>>
>> So this is not needed in kvm tree?
>> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue&id=3a792199004ec335346cc607d62600a399a7ee02
>>
>
> Hmm I would think that my patch would be more appropiate as it
> actually does
> what the comment says.
The static key controls the behavior of the locking slowpath which will
not be executed at all. So it is essentially a no-op.
-Longman
next prev parent reply other threads:[~2018-07-23 13:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-19 21:39 [PATCH v2] xen/spinlock: Don't use pvqspinlock if only 1 vCPU Waiman Long
2018-07-19 21:54 ` Davidlohr Bueso
2018-07-19 21:54 ` Davidlohr Bueso
2018-07-19 22:02 ` Waiman Long
2018-07-19 22:02 ` Waiman Long
2018-07-23 3:31 ` Wanpeng Li
2018-07-23 3:31 ` Wanpeng Li
2018-07-23 4:42 ` Davidlohr Bueso
2018-07-23 4:42 ` Davidlohr Bueso
2018-07-23 4:50 ` Davidlohr Bueso
2018-07-23 4:50 ` Davidlohr Bueso
2018-07-23 13:52 ` Waiman Long [this message]
2018-07-23 13:52 ` Waiman Long
2018-07-23 13:33 ` Waiman Long
2018-07-23 13:33 ` Waiman Long
2018-07-19 22:35 ` Boris Ostrovsky
2018-07-19 22:35 ` Boris Ostrovsky
2018-07-31 17:05 ` Boris Ostrovsky
2018-07-31 17:05 ` Boris Ostrovsky
-- strict thread matches above, loose matches on Subject: below --
2018-07-19 21:39 Waiman Long
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=434efa92-844d-46d0-65c4-86eb6365f024@redhat.com \
--to=longman@redhat.com \
--cc=boris.ostrovsky@oracle.com \
--cc=dave@stgolabs.net \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=kernellwp@gmail.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.