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