From: Joel Fernandes <joelagnelf@nvidia.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Uladzislau Rezki <urezki@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>, rcu <rcu@vger.kernel.org>
Subject: Re: [PATCH 1/5] rcu/exp: Protect against early QS report
Date: Sun, 16 Mar 2025 10:23:45 -0400 [thread overview]
Message-ID: <65d7e2db-2293-4fa5-ae73-bcbaa60c01f3@nvidia.com> (raw)
In-Reply-To: <Z9aw252VPvW9K4Wl@pavilion.home>
On 3/16/2025 7:07 AM, Frederic Weisbecker wrote:
>>> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
>>> index c36c7d5575ca..2fa7aa9155bd 100644
>>> --- a/kernel/rcu/tree_exp.h
>>> +++ b/kernel/rcu/tree_exp.h
>>> @@ -141,6 +141,13 @@ static void __maybe_unused sync_exp_reset_tree(void)
>>> raw_spin_lock_irqsave_rcu_node(rnp, flags);
>>> WARN_ON_ONCE(rnp->expmask);
>>> WRITE_ONCE(rnp->expmask, rnp->expmaskinit);
>>> + /*
>>> + * Need to wait for any blocked tasks as well. Note that
>>> + * additional blocking tasks will also block the expedited GP
>>> + * until such time as the ->expmask bits are cleared.
>>> + */
>>> + if (rcu_is_leaf_node(rnp) && rcu_preempt_has_tasks(rnp))
>>> + WRITE_ONCE(rnp->exp_tasks, rnp->blkd_tasks.next);
>>> raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
>>> }
>>> }
>>> @@ -393,13 +400,6 @@ static void __sync_rcu_exp_select_node_cpus(struct rcu_exp_work *rewp)
>>> }
>>> mask_ofl_ipi = rnp->expmask & ~mask_ofl_test;
>>>
>>> - /*
>>> - * Need to wait for any blocked tasks as well. Note that
>>> - * additional blocking tasks will also block the expedited GP
>>> - * until such time as the ->expmask bits are cleared.
>>> - */
>>> - if (rcu_preempt_has_tasks(rnp))
>>> - WRITE_ONCE(rnp->exp_tasks, rnp->blkd_tasks.next);
>>> raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
>> A small side effect of this patch could be:
>>
>> In the existing code, if between the sync_exp_reset_tree() and the
>> __sync_rcu_exp_select_node_cpus(), if a pre-existing reader unblocked and
>> completed, then I think it wouldn't be responsible for blocking the GP
>> anymore.
> Hmm, I don't see how that changes after this patch.
>
>> Where as with this patch, it would not get a chance to be removed from the
>> blocked list because it would have to wait on the rnp lock, which after this
>> patch would now be held across the setting of exp_mask and exp_tasks?
> So that's sync_exp_reset_tree(). I'm a bit confused. An unblocking task
> contend on rnp lock in any case. But after this patch it is still going
> to remove itself from the blocking task once the rnp lock is released by
> sync_exp_reset_tree().
>
> What am I missing?
You are probably not missing anything and I'm the one missing something.
But I was thinking:
In in the original code, in __sync_rcu_exp_select_node_cpus() if
rcu_preempt_has_tasks() returns FALSE because of the finer grained locking, then
there is a chance for the GP to conclude sooner,
On the other hand, after the patch because the unblocking task had to wait (on
the lock) to remove itself from the blocked task list, the GP may conclude later
than usual. This is just an intuitive guess.
Because this is an expedited GP, my intuition is to unblock + reader unlock and
get out of the way ASAP than hoping that it will get access to the lock before
any IPIs go out or quiescent state reports/checks happen which are required to
conclude the GP
Its just a theory and you're right, if it acquires the lock soon enough and gets
out of the way, then it doesn't matter either way.
Thanks!
- Joel
next prev parent reply other threads:[~2025-03-16 14:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-14 14:36 [PATCH 0/5 v2] rcu/exp updates Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 1/5] rcu/exp: Protect against early QS report Frederic Weisbecker
2025-03-15 23:59 ` Joel Fernandes
2025-03-16 11:07 ` Frederic Weisbecker
2025-03-16 14:23 ` Joel Fernandes [this message]
2025-03-16 22:24 ` Frederic Weisbecker
2025-03-18 17:17 ` Paul E. McKenney
2025-03-19 8:58 ` Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 2/5] rcu/exp: Remove confusing needless full barrier on task unblock Frederic Weisbecker
2025-03-18 17:18 ` Paul E. McKenney
2025-03-19 9:01 ` Frederic Weisbecker
2025-03-19 14:03 ` Paul E. McKenney
2025-03-14 14:36 ` [PATCH 3/5] rcu/exp: Remove needless CPU up quiescent state report Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 4/5] rcu/exp: Warn on QS requested on dying CPU Frederic Weisbecker
2025-03-18 17:21 ` Paul E. McKenney
2025-03-19 9:14 ` Frederic Weisbecker
2025-03-14 14:36 ` [PATCH 5/5] rcu/exp: Warn on CPU lagging for too long within hotplug IPI's blindspot Frederic Weisbecker
2025-03-18 17:22 ` Paul E. McKenney
2025-03-19 9:42 ` Frederic Weisbecker
2025-03-19 14:04 ` Paul E. McKenney
2025-04-29 13:42 [PATCH 0/5 v3] rcu/exp updates Frederic Weisbecker
2025-04-29 13:43 ` [PATCH 1/5] rcu/exp: Protect against early QS report Frederic Weisbecker
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=65d7e2db-2293-4fa5-ae73-bcbaa60c01f3@nvidia.com \
--to=joelagnelf@nvidia.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neeraj.upadhyay@amd.com \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=urezki@gmail.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
all inboxes | Powered by JetHome®