From: Chen Yu <yu.c.chen@intel.com>
To: Dave Hansen <dave.hansen@intel.com>, Juergen Gross <jgross@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Juergen Gross <jgross@suse.com>,
Ajay Kaher <ajay.kaher@broadcom.com>,
Alexey Makhalov <alexey.amakhalov@broadcom.com>,
Arnd Bergmann <arnd@arndb.de>, "H. Peter Anvin" <hpa@zytor.com>,
<x86@kernel.org>, <virtualization@lists.linux.dev>,
<linux-kernel@vger.kernel.org>, Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
Prem Nath Dey <prem.nath.dey@intel.com>,
"Xiaoping Zhou" <xiaoping.zhou@intel.com>
Subject: Re: [PATCH] x86/paravirt: Disable virt spinlock when CONFIG_PARAVIRT_SPINLOCKS disabled
Date: Sat, 25 May 2024 14:03:26 +0800 [thread overview]
Message-ID: <ZlF/Lrr4nWqVpoc8@chenyu5-mobl2> (raw)
In-Reply-To: <7b8d1dd6-3913-45fe-941e-aac2c15916dc@intel.com>
On 2024-05-23 at 09:30:59 -0700, Dave Hansen wrote:
> On 5/16/24 06:02, Chen Yu wrote:
> > Performance drop is reported when running encode/decode workload and
> > BenchSEE cache sub-workload.
> > Bisect points to commit ce0a1b608bfc ("x86/paravirt: Silence unused
> > native_pv_lock_init() function warning"). When CONFIG_PARAVIRT_SPINLOCKS
> > is disabled the virt_spin_lock_key is set to true on bare-metal.
> > The qspinlock degenerates to test-and-set spinlock, which decrease the
> > performance on bare-metal.
> >
> > Fix this by disabling virt_spin_lock_key if CONFIG_PARAVIRT_SPINLOCKS
> > is not set, or it is on bare-metal.
>
> This is missing some background:
>
> The kernel can change spinlock behavior when running as a guest. But
> this guest-friendly behavior causes performance problems on bare metal.
> So there's a 'virt_spin_lock_key' static key to switch between the two
> modes.
>
> The static key is always enabled by default (run in guest mode) and
> should be disabled for bare metal (and in some guests that want native
> behavior).
>
> ... then describe the regression and the fix
>
Thanks Juergen for your review.
And thanks Dave for the write up, I'll refine the log according to your suggestion.
> > diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> > index 5358d43886ad..ee51c0949ed8 100644
> > --- a/arch/x86/kernel/paravirt.c
> > +++ b/arch/x86/kernel/paravirt.c
> > @@ -55,7 +55,7 @@ DEFINE_STATIC_KEY_TRUE(virt_spin_lock_key);
> >
> > void __init native_pv_lock_init(void)
> > {
> > - if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) &&
> > + if (!IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS) ||
> > !boot_cpu_has(X86_FEATURE_HYPERVISOR))
> > static_branch_disable(&virt_spin_lock_key);
> > }
> This gets used at a single site:
>
> if (pv_enabled())
> goto pv_queue;
>
> if (virt_spin_lock(lock))
> return;
>
> which is logically:
>
> if (IS_ENABLED(CONFIG_PARAVIRT_SPINLOCKS))
> goto ...; // don't look at virt_spin_lock_key
>
> if (virt_spin_lock_key)
> return; // On virt, but non-paravirt. Did Test-and-Set
> // spinlock.
>
Thanks for the description in detail, my original change might break the
"X86_FEATURE_HYPERVISOR + NO_CONFIG_PARAVIRT_SPINLOCKS " case that, the guest
can not fall into test-and-set.
> So I _think_ Arnd was trying to optimize native_pv_lock_init() away when
> it's going to get skipped over anyway by the 'goto'.
>
> But this took me at least 30 minutes of scratching my head and trying to
> untangle the whole thing. It's all far too subtle for my taste, and all
> of that to save a few bytes of init text in a configuration that's
> probably not even used very often (PARAVIRT=y, but PARAVIRT_SPINLOCKS=n).
>
> Let's just keep it simple. How about the attached patch?
Yes, this one works, I'll refine it.
thanks,
Chenyu
prev parent reply other threads:[~2024-05-25 6:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 13:02 [PATCH] x86/paravirt: Disable virt spinlock when CONFIG_PARAVIRT_SPINLOCKS disabled Chen Yu
2024-05-23 10:04 ` Juergen Gross
2024-05-23 16:30 ` Dave Hansen
2024-05-23 18:39 ` Jürgen Groß
2024-05-23 18:44 ` Dave Hansen
2024-05-25 6:03 ` Chen Yu [this message]
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=ZlF/Lrr4nWqVpoc8@chenyu5-mobl2 \
--to=yu.c.chen@intel.com \
--cc=ajay.kaher@broadcom.com \
--cc=alexey.amakhalov@broadcom.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=prem.nath.dey@intel.com \
--cc=qiuxu.zhuo@intel.com \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux.dev \
--cc=x86@kernel.org \
--cc=xiaoping.zhou@intel.com \
/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