lkml.org 
[lkml]   [2008]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] RCU: implement rcu_read_[un]lock_preempt()
Peter Zijlstra wrote:
>>> 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.
>
> Should be really cheap then, because the cacheline is already hot.

Yeah, it is, so it is eventually a peripheral issue.

>> 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.
>
> They only overlap for !PREEMPT_RCU || !PREEMPT_RT

That part is pretty large tho.

>> 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 don't as its a nightmare to sort out on -rt, where get_cpu() can be
> converted to get_cpu_locked(), and rcu_read_lock() never disables
> preemption.
>
> If you convert it to use get_cpu() the conversion is easy, if you
> introduce this collapsed primitive we're up shit creek because it
> doesn't map.

I don't get it. So, rcu_read_lock(); preempt_disable(); doesn't map for RT?

> Nor does it tell us why you need preempt disabled. Making it just as bad
> as open-coded preempt_disable()s.

Heh.. the code probably would have used preempt_disable() if it were not
for the combined ops, so the objection is about using preempt_disable()?

--
tejun


\
 
 \ /
  Last update: 2008-07-29 03:51    [W:0.100 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site