Messages in this thread | | | Date | Thu, 30 Apr 2009 10:12:11 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [ltt-dev] [PATCH] Fix dirty page accounting in redirty_page_for_writepage() |
| |
* Christoph Lameter (cl@linux.com) wrote: > On Thu, 30 Apr 2009, Ingo Molnar wrote: > > > > I see however that it's only guaranteed to be atomic wrt preemption. > > > > That's really only true for the non-x86 fallback defines. If we so > > decide, we could make the fallbacks in asm-generic/percpu.h irq-safe > > The fallbacks have different semantics and therefore we cannot rely on > irq safeness in the core code when using the x86 cpu ops. > > > nmi-safe isnt a big issue (we have no NMI code that interacts with > > MM counters) - and we could make them irq-safe by fixing the > > wrapper. (and on x86 they are NMI-safe too.) > > There are also context in which you alrady are preempt safe and where the > per cpu ops do not need to go through the prremption hoops. > > This means it would be best to have 3 variants for 3 different contexts in > the core code: > > 1. Need irq safety > 2. Need preempt safety > 3. We know the operation is safe due to preemption already having been > disabled or irqs are not enabled. > > The 3 variants on x86 generate the same instructions. On other platforms > they would need to be able to fallback in various way depending on the > availability of instructions that are atomic vs. preempt or irqs. >
The problem here, as we did figure out a while ago with the atomic slub we worked on a while ago, is that if we have the following code :
local_irq_save var++ var++ local_irq_restore
that we would like to turn into irq-safe percpu variant with this semantic :
percpu_add_irqsafe(var) percpu_add_irqsafe(var)
We are generating two irq save/restore in the fallback, which will be slow.
However, we could do the following trick :
percpu_irqsave(flags); percpu_add_irq(var); percpu_add_irq(var); percpu_irqrestore(flags);
And we could require that percpu_*_irq operations are put within a irq safe section. The fallback would disable interrupts, but arch-specific irq-safe atomic implementations would replace this by nops.
And if interrupts are already disabled, percpu_add_irq could be used directly. There is no need to duplicate the primitives (no _percpu_add_irq() needed). Same could apply to preempt-safety :
percpu_preempt_disable(); percpu_add(var); percpu_add(var); percpu_preempt_enable();
Where requirements on percpu_add would be to be called within a percpu_preempt_disable/percpu_preempt_enable section or to be sure that preemption is already disabled around.
Same thing could apply to bh. But I don't see any difference between percpu_add_bh and percpu_add_irq, except maybe on architectures which would use tri-values :
percpu_bh_disable(); percpu_add_bh(var); percpu_add_bh(var); percpu_bh_enable();
Thoughts ?
Mathieu
> http://thread.gmane.org/gmane.linux.kernel.cross-arch/1124 > http://lwn.net/Articles/284526/ > > -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |