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 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.