From: "Paul E. McKenney" <paulmck@kernel.org>
To: "Zhang,Qiang" <qiang.zhang@windriver.com>
Cc: "rcu@vger.kernel.org" <rcu@vger.kernel.org>,
Joel Fernandes <joel@joelfernandes.org>
Subject: Re: SRCU: Question on srcu_advance_state
Date: Fri, 20 Nov 2020 17:11:32 -0800 [thread overview]
Message-ID: <20201121011132.GR1437@paulmck-ThinkPad-P72> (raw)
In-Reply-To: <7fc7b6b9-bcf2-fa78-1931-415d04a5ac1a@windriver.com>
On Fri, Nov 20, 2020 at 04:30:15PM +0800, Zhang,Qiang wrote:
> Hello Pual
>
> sorry to disturb you, I also have some quesetion for you:
>
> in srcu_advance_state function, when seq state == SRCU_STATE_SCAN1, we will
> check, if the previous readers critical region exits, will be returned
> directly.
>
> I'd like to know under what scenario this will happen?
Suppose that a reader gets preempted for a very long time in the
middle of __srcu_read_lock():
int __srcu_read_lock(struct srcu_struct *ssp)
{
int idx;
idx = READ_ONCE(ssp->srcu_idx) & 0x1;
// PREEMPTED RIGHT HERE
this_cpu_inc(ssp->sda->srcu_lock_count[idx]);
smp_mb(); /* B */ /* Avoid leaking the critical section. */
return idx;
}
Suppose that several SRCU grace periods elapse during that preemption.
Do you see how that can lead to your SRCU_STATE_SCAN1 early exit?
Thanx, Paul
PS: The paper below outlines a similar situation in userspace RCU,
so feel free to use this paper as a hint. The paper is in two
pieces, with the first piece in the first URL and the second in
either of the last two URLs.
@article{MathieuDesnoyers2012URCU,
Author="Mathieu Desnoyers and Paul E. McKenney and Alan Stern and Michel R. Dagenais and Jonathan Walpole",
Title="User-Level Implementations of Read-Copy Update",
journal="IEEE Transactions on Parallel and Distributed Systems",
volume={23},
year="2012",
issn="1045-9219",
pages="375-382",
doi="10.1109/TPDS.2011.159",
publisher="IEEE Computer Society",
address="Los Alamitos, CA, USA",
annotation={
RCU overview, desiderata, semi-formal semantics, user-level RCU
usage scenarios, three classes of RCU implementation, wait-free
RCU updates, RCU grace-period batching, update overhead,
http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf
http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf
http://www.computer.org/cms/Computer.org/dl/trans/td/2012/02/extras/ttd2012020375s.pdf
},
}
next prev parent reply other threads:[~2020-11-21 1:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-20 8:30 SRCU: Question on srcu_advance_state Zhang,Qiang
2020-11-21 1:11 ` Paul E. McKenney [this message]
2020-11-23 1:59 ` 回复: " Zhang, Qiang
2020-11-25 3:03 ` Paul E. McKenney
2020-11-27 8:19 ` 回复: " Zhang, Qiang
2020-12-02 18:10 ` Paul E. McKenney
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=20201121011132.GR1437@paulmck-ThinkPad-P72 \
--to=paulmck@kernel.org \
--cc=joel@joelfernandes.org \
--cc=qiang.zhang@windriver.com \
--cc=rcu@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).