Messages in this thread | | | Date | Thu, 8 Oct 2009 13:22:21 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [this_cpu_xx V5 19/19] SLUB: Experimental new fastpath w/o interrupt disable |
| |
* Peter Zijlstra (peterz@infradead.org) wrote: > On Thu, 2009-10-08 at 08:44 -0400, Mathieu Desnoyers wrote: > > Even if only done with interrupt off, and check resched is called after > > each irq enable following this critical section ? I'd like to understand > > the reason behind your rejection for this specific case. > > No, the thing you proposed: > > > preempt disable() > > fast path attempt > > if (fast path already taken) { > > local_irq_save(); > > preempt_enable_no_resched(); > > slow path { > > if (!flags & GFP_ATOMIC) { > > local_irq_enable(); > > preempt_check_resched(); > > ... > > local_irq_disable(); > > } > > } > > local_irq_restore(); > > preempt_check_resched(); > > return; > > } > > preempt_enable() > > Seems ok. > > I just don't get why Christoph is getting all upset about the > need_resched() check in preempt_enable(), its still cheaper than poking > at the interrupt flags.
I agree with you. need_resched() check is incredibly cheap. And if Christoph still complains about the compiler barrier in preempt enable_no_resched/disable, then I think he should consider the fact that the compiler does not perform cross-function optimizations, and consider putting the preempt disable/enable statements close to function boundaries. Therefore, the impact in terms of compiler optimization restrictions should be minimal.
The scheme I proposed above should be OK in terms of scheduler effect and permit to deal with re-enabling preemption in the slow path appropriately.
Mathieu
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |