All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neeraj Upadhyay <quic_neeraju@quicinc.com>
To: David Woodhouse <dwmw2@infradead.org>,
	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 v1.1 02/11] rcu: Kill rnp->ofl_seq and use only rcu_state.ofl_lock for exclusion
Date: Mon, 13 Dec 2021 14:41:13 +0530	[thread overview]
Message-ID: <571def82-92c8-e7e5-74d6-4a7cfc225977@quicinc.com> (raw)
In-Reply-To: <1b4f10dd64e0288443fe7dbf706d5d5560cf98f4.camel@infradead.org>


On 12/13/2021 2:27 PM, David Woodhouse wrote:
> On Fri, 2021-12-10 at 09:56 +0530, Neeraj Upadhyay wrote:
>>> -	if (rdp->grpmask & rcu_rnp_online_cpus(rnp) || READ_ONCE(rnp->ofl_seq) & 0x1)
>>> +	/*
>>> +	 * Strictly, we care here about the case where the current CPU is
>>> +	 * in rcu_cpu_starting() and thus has an excuse for rdp->grpmask
>>> +	 * not being up to date. So arch_spin_is_locked() might have a
>>
>> Minor:
>>
>> Is this comment right - "thus has an excuse for rdp->grpmask not being
>> up to date"; shouldn't it be "thus has an excuse for rnp->qsmaskinitnext
>> not being up to date"?
>>
>> Also, arch_spin_is_locked() also handles the rcu_report_dead() case,
>> where raw_spin_unlock_irqrestore_rcu_node() can have a rcu_read_lock
>> from lockdep path with CPU bits already cleared from rnp->qsmaskinitnext?
> 
> Good point; thanks. How's this:
> 
> 	/*
> 	 * Strictly, we care here about the case where the current CPU is in
> 	 * rcu_cpu_starting() or rcu_report_dead() and thus has an excuse for
> 	 * rdp->qsmaskinitnext not being up to date. So arch_spin_is_locked()
> 	 * might have a false positive if it's held by some *other* CPU, but
> 	 * that's OK because that just means a false *negative* on the
> 	 * warning.
> 	 */
> 

Looks good to me!



>>>   	if (WARN_ON_ONCE(rnp->qsmask & mask)) { /* RCU waiting on incoming CPU? */
>>> +		/* rcu_report_qs_rnp() *really* wants some flags to restore */
>>> +		unsigned long flags2;
>>
>> Minor: checkpatch flags it "Missing a blank line after declarations"
> 
> Ack. Also fixed and pushed out to my parallel-5.16 branch at
> https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/parallel-5.16
> > This commit is probably the only one that's strictly needed for that
> parallel bringup, but for now I've kept my rcu boost thread mutex
> patch, and added your two patches (with minor whitespace fixes). I
> think the best option is to let Paul handle them all.
> 

Thanks; the 4 RCU specific patches in that tree looks good to me.


Thanks
Neeraj

> We'll do the final step of actually *enabling* the parallel bringup on
> any given architecture only after the various fixes have made their way
> in and we've done a proper review of the remaining code paths.
> 
> 

  reply	other threads:[~2021-12-13  9:11 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
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 [this message]
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=571def82-92c8-e7e5-74d6-4a7cfc225977@quicinc.com \
    --to=quic_neeraju@quicinc.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw2@infradead.org \
    --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=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.