From: Peter Zijlstra <peterz@infradead.org>
To: Tejun Heo <tj@kernel.org>
Cc: dipankar@in.ibm.com, Andrew Morton <akpm@linux-foundation.org>,
Jens Axboe <jens.axboe@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Paul E McKenney <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] RCU: implement rcu_read_[un]lock_preempt()
Date: Wed, 16 Jul 2008 08:07:49 +0200 [thread overview]
Message-ID: <1216188469.5232.0.camel@twins> (raw)
In-Reply-To: <487AEAC6.60307@kernel.org>
On Mon, 2008-07-14 at 14:57 +0900, Tejun Heo wrote:
> With the introduction of preemptible RCU, RCU doesn't gurantee that
> its critical section runs on the CPU it started to run. As there are
> cases where non-preemptible RCU critical section makes sense, create
> new RCU read lock variants which turns of preemption -
> rcu_read_[un]lock_preempt() which are identical to rcu_read_[un]lock()
> for classic implementation and have enclosing preempt disable/enable
> for preemptible RCU.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
Sorry, NAK.
If you need preempt off you need it for other reasons than RCU, so
mixing it in the interface doesn't make sense to me.
> ---
> This will be used by following block layer updates. If this and the
> block changes get acked, it'll be best to push this through block
> tree.
>
> Thanks.
>
> include/linux/rcuclassic.h | 2 ++
> include/linux/rcupdate.h | 18 ++++++++++++++++++
> include/linux/rcupreempt.h | 6 ++++--
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/rcuclassic.h b/include/linux/rcuclassic.h
> index b3aa05b..08c6153 100644
> --- a/include/linux/rcuclassic.h
> +++ b/include/linux/rcuclassic.h
> @@ -136,6 +136,8 @@ extern struct lockdep_map rcu_lock_map;
> __release(RCU); \
> preempt_enable(); \
> } while (0)
> +#define __rcu_read_lock_preempt() __rcu_read_lock()
> +#define __rcu_read_unlock_preempt() __rcu_read_unlock()
> #define __rcu_read_lock_bh() \
> do { \
> local_bh_disable(); \
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index d42dbec..e0e3486 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -112,6 +112,24 @@ struct rcu_head {
> #define rcu_read_unlock() __rcu_read_unlock()
>
> /**
> + * rcu_read_lock_preempt - mark the beginning of non-preemptible RCU
> + * critical section
> + *
> + * Identical to rcu_read_lock() but the critical section is guaranteed
> + * to be non-preemptible. Note that this is identical to
> + * rcu_read_lock() on classic RCU implementation.
> + */
> +#define rcu_read_lock_preempt() __rcu_read_lock_preempt()
> +
> +/**
> + * rcu_read_unlock_preempt - mark the end of of non-preemptible RCU
> + * critical section
> + *
> + * See rcu_read_lock_preempt() for more information.
> + */
> +#define rcu_read_unlock_preempt() __rcu_read_unlock_preempt()
> +
> +/**
> * rcu_read_lock_bh - mark the beginning of a softirq-only RCU critical section
> *
> * This is equivalent of rcu_read_lock(), but to be used when updates
> diff --git a/include/linux/rcupreempt.h b/include/linux/rcupreempt.h
> index 8a05c7e..b263ceb 100644
> --- a/include/linux/rcupreempt.h
> +++ b/include/linux/rcupreempt.h
> @@ -49,8 +49,10 @@ extern void __rcu_read_unlock(void) __releases(RCU);
> extern int rcu_pending(int cpu);
> extern int rcu_needs_cpu(int cpu);
>
> -#define __rcu_read_lock_bh() { rcu_read_lock(); local_bh_disable(); }
> -#define __rcu_read_unlock_bh() { local_bh_enable(); rcu_read_unlock(); }
> +#define __rcu_read_lock_preempt() { rcu_read_lock(); preempt_disable(); }
> +#define __rcu_read_unlock_preempt() { preempt_enable(); rcu_read_unlock(); }
> +#define __rcu_read_lock_bh() { rcu_read_lock(); local_bh_disable(); }
> +#define __rcu_read_unlock_bh() { local_bh_enable(); rcu_read_unlock(); }
>
> extern void __synchronize_sched(void);
>
next prev parent reply other threads:[~2008-07-16 6:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-14 5:57 [PATCH] RCU: implement rcu_read_[un]lock_preempt() Tejun Heo
2008-07-16 6:07 ` Peter Zijlstra [this message]
2008-07-16 6:43 ` Tejun Heo
2008-07-28 15:13 ` Peter Zijlstra
2008-07-29 1:47 ` Tejun Heo
2008-07-29 6:15 ` Peter Zijlstra
2008-07-30 1:15 ` Tejun Heo
2008-08-01 21:10 ` Paul E. McKenney
2008-08-01 23:06 ` Peter Zijlstra
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=1216188469.5232.0.camel@twins \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=dipankar@in.ibm.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tj@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