From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: linux-kernel@us.ibm.com
Cc: akpm@osdl.org, matthltc@us.ibm.com, dipankar@in.ibm.com,
stern@rowland.harvard.edu, mingo@elte.hu, tytso@us.ibm.com,
dvhltc@us.ibm.com, oleg@tv-sign.ru, jes@sgi.com
Subject: [PATCH 0/2] srcu-3: add RCU variant that permits read-side blocking
Date: Thu, 6 Jul 2006 10:14:01 -0700 [thread overview]
Message-ID: <20060706171401.GA1768@us.ibm.com> (raw)
Version 3 of the SRCU patchset.
This patch incorporates a number of improvements, many of which came
up in off-list discussions with Alan Stern. Neither of us are sure
why these discussions ended up off-list, so I have summarized them
below.
o Fixes some "zombie code" -- excess curly braces and the like.
o Gets rid of the double-flip in favor of an additional
synchronize_sched(). This turned out to be safe, despite
my saying otherwise at http://lkml.org/lkml/2006/6/27/486.
The trick that I was missing is that synchronize_sched()
forces all CPUs to execute at least one memory barrier during
the synchronize_sched()'s execution, which forces all CPUs
to see synchronize_srcu()'s counter increment as happening
after any memory manipulations prior to the synchronize_srcu().
Upgraded comments to indicate what the synchronize_sched()
calls are needed for.
o Added a barrier() to both srcu_read_lock() and srcu_read_unlock()
to prevent the compiler from performing optimizations that
would cause the critical section to move outside of the
enclosing srcu_read_lock() and srcu_read_unlock().
However, these barrier()s in srcu_read_lock() and srcu_read_unlock()
are needed only in non-CONFIG_PREEMPT kernels, so they compile
to nothing in CONFIG_PREEMPT kernels (where the preempt_disable()
and preempt_enable() calls supply the needed barrier() call).
o Added a check to synchronize_srcu() that permits this primitive
to take advantage of grace periods induced by concurrent executions
in other tasks. This can be useful in cases where you are
using a single srcu_struct to handle all the individually-locked
chains of a hash table, for example.
o cleanup_srcu_struct() now contains error checks to catch cases
where readers are still using the srcu_struct in question.
It does a WARN_ON() and leaks the srcu_struct's per-CPU data
in that case.
o There is an srcu_readers_active() that returns the number of
readers (approximate!) currently using the specified srcu_struct.
This can be useful when terminating use of an srcu_struct, e.g.,
at module-unload time.
o Improved the RCU torture tests, increasing the skew on reader
times and providing implementation-specific delay functions.
next reply other threads:[~2006-07-06 18:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-06 17:14 Paul E. McKenney [this message]
2006-07-06 17:20 ` [PATCH 1/2] srcu-3: RCU variant permitting read-side blocking Paul E. McKenney
[not found] ` <20060709235029.GA194@oleg>
2006-07-10 16:51 ` Paul E. McKenney
[not found] ` <44B29212.1070301@yahoo.com.au>
2006-07-11 14:19 ` Paul E. McKenney
2006-07-06 17:25 ` [PATCH 2/2] srcu-3: add SRCU operations to rcutorture 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=20060706171401.GA1768@us.ibm.com \
--to=paulmck@us.ibm.com \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=jes@sgi.com \
--cc=linux-kernel@us.ibm.com \
--cc=matthltc@us.ibm.com \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=stern@rowland.harvard.edu \
--cc=tytso@us.ibm.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