From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.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 15:43:56 +0900 [thread overview]
Message-ID: <487D98AC.3020005@kernel.org> (raw)
In-Reply-To: <1216188469.5232.0.camel@twins>
Peter Zijlstra wrote:
> 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.
Hmmm... the point of the interface is avoiding doing double preemption
operations as on common configurations rcu_read_lock() disables
preemption. Yes, it's for different purposes but we have two partially
overlapping ops and implementing combined / collapsed ops for such cases
is acceptable, I think.
Using get_cpu() or separate preempt_disable() wouldn't incur noticeable
performance difference as preemption is really cheap to manipulate but
both per-cpu and RCU are for performance optimization and I think having
combined ops is a good idea.
I wonder what other people think. If it's agreed that having combined
ops is a bad idea, I'll convert it to get_cpu().
Thanks.
--
tejun
next prev parent reply other threads:[~2008-07-19 10:23 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
2008-07-16 6:43 ` Tejun Heo [this message]
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=487D98AC.3020005@kernel.org \
--to=tj@kernel.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=peterz@infradead.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.