On Thu, 18 Aug 2011 16:41:53 +0200, Johannes Weiner said: > On Thu, Aug 18, 2011 at 10:26:58AM -0400, Valdis.Kletnieks@xxxxxx wrote: > > On Thu, 18 Aug 2011 11:38:00 +0200, Johannes Weiner said: > > > > > Note that on non-x86, these operations themselves actually disable and > > > reenable preemption each time, so you trade a pair of add and sub on > > > x86 > > > > > > - preempt_disable() > > > __this_cpu_xxx() > > > __this_cpu_yyy() > > > - preempt_enable() > > > > > > with > > > > > > preempt_disable() > > > __this_cpu_xxx() > > > + preempt_enable() > > > + preempt_disable() > > > __this_cpu_yyy() > > > preempt_enable() > > > > > > everywhere else. > > > > That would be an unexpected race condition on non-x86, if you expected _xxx and > > _yyy to be done together without a preempt between them. Would take mere > > mortals forever to figure that one out. :) > > That should be fine, we don't require the two counters to be perfectly > coherent with respect to each other, which is the justification for > this optimization in the first place. I meant the general case - when reviewing code, I wouldn't expect 2 lines of code wrapped in preempt disable/enable to have a preempt window in the middle. ;)
Attachment:
pgpPuYYL0d4qe.pgp
Description: PGP signature