From: David Woodhouse <dwmw2@infradead.org>
To: Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
rcu@vger.kernel.org, mimoja@mimoja.de, hewenliang4@huawei.com,
hushiyuan@huawei.com, luolongjun@huawei.com,
hejingxian@huawei.com
Subject: Re: [PATCH 02/11] rcu: Kill rnp->ofl_seq and use only rcu_state.ofl_lock for exclusion
Date: Thu, 09 Dec 2021 18:43:30 +0000 [thread overview]
Message-ID: <3731b8da4dc46febc8adef331d6c97b21283428a.camel@infradead.org> (raw)
In-Reply-To: <dfa110f0-8fd0-0f37-2c37-89eccac1ad08@quicinc.com>
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
On Fri, 2021-12-10 at 00:01 +0530, Neeraj Upadhyay wrote:
> > @@ -4246,11 +4249,11 @@ void rcu_cpu_starting(unsigned int cpu)
> >
> > rnp = rdp->mynode;
> > mask = rdp->grpmask;
> > - WRITE_ONCE(rnp->ofl_seq, rnp->ofl_seq + 1);
> > - WARN_ON_ONCE(!(rnp->ofl_seq & 0x1));
> > + local_irq_save(seq_flags);
> > + arch_spin_lock(&rcu_state.ofl_lock);
> > rcu_dynticks_eqs_online();
> > smp_mb(); // Pair with rcu_gp_cleanup()'s ->ofl_seq barrier().
>
> Can we drop this smp_mb(),as arch_spin_lock(&rcu_state.ofl_lock)
> provides the ordering now?
Yes, thanks.
> > - raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > + raw_spin_lock_rcu_node(rnp);
> > WRITE_ONCE(rnp->qsmaskinitnext, rnp->qsmaskinitnext | mask);
> > newcpu = !(rnp->expmaskinitnext & mask);
> > rnp->expmaskinitnext |= mask;
> > @@ -4269,9 +4272,8 @@ void rcu_cpu_starting(unsigned int cpu)
> > } else {
> > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
>
> 'flags' is uninitialized now?
Ah yes, that suffered from the fact that saving the flags is pointless
because we know we already disabled interrupts... but
rcu_report_qs_rnp() *really* wants to be given some flags to restore.
Will fix that too; thanks again.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
next prev parent reply other threads:[~2021-12-09 18:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 15:09 [PATCH 00/11] Parallel CPU bringup for x86_64 David Woodhouse
2021-12-09 15:09 ` [PATCH 01/11] x86/apic/x2apic: Fix parallel handling of cluster_mask David Woodhouse
2021-12-09 15:09 ` [PATCH 02/11] rcu: Kill rnp->ofl_seq and use only rcu_state.ofl_lock for exclusion David Woodhouse
2021-12-09 17:18 ` Paul E. McKenney
2021-12-09 18:52 ` David Woodhouse
2021-12-09 18:31 ` Neeraj Upadhyay
2021-12-09 18:43 ` David Woodhouse [this message]
2021-12-09 19:21 ` [PATCH v1.1 " David Woodhouse
2021-12-10 4:26 ` Neeraj Upadhyay
2021-12-13 8:57 ` David Woodhouse
2021-12-13 9:11 ` Neeraj Upadhyay
2021-12-09 15:09 ` [PATCH 03/11] rcu: Add mutex for rcu boost kthread spawning and affinity setting David Woodhouse
2021-12-09 17:20 ` Paul E. McKenney
2021-12-09 15:09 ` [PATCH 04/11] cpu/hotplug: Add dynamic parallel bringup states before CPUHP_BRINGUP_CPU David Woodhouse
2021-12-09 15:09 ` [PATCH 05/11] x86/smpboot: Reference count on smpboot_setup_warm_reset_vector() David Woodhouse
2021-12-09 15:09 ` [PATCH 06/11] x86/smpboot: Split up native_cpu_up into separate phases David Woodhouse
2021-12-09 15:09 ` [PATCH 07/11] cpu/hotplug: Move idle_thread_get() to <linux/smpboot.h> David Woodhouse
2021-12-09 15:09 ` [PATCH 08/11] x86/tsc: Avoid synchronizing TSCs with multiple CPUs in parallel David Woodhouse
2021-12-09 15:43 ` Peter Zijlstra
2021-12-09 15:50 ` David Woodhouse
2021-12-09 15:09 ` [PATCH 09/11] x86/boot: Support parallel startup of secondary CPUs David Woodhouse
2021-12-09 15:50 ` Peter Zijlstra
2021-12-14 11:33 ` David Woodhouse
2021-12-09 15:09 ` [PATCH 10/11] x86/smp: Bring up secondary CPUs in parallel David Woodhouse
2021-12-09 15:09 ` [PATCH 11/11] x86/kvm: Silence per-cpu pr_info noise about KVM clocks and steal time David Woodhouse
2021-12-09 17:39 ` Paolo Bonzini
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=3731b8da4dc46febc8adef331d6c97b21283428a.camel@infradead.org \
--to=dwmw2@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hejingxian@huawei.com \
--cc=hewenliang4@huawei.com \
--cc=hpa@zytor.com \
--cc=hushiyuan@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luolongjun@huawei.com \
--cc=mimoja@mimoja.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.