All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.