[ltt-dev] [PATCH] Fix dirty page accounting in redirty_page_for_writepage()

[Linus Torvalds]

On Thu, 30 Apr 2009, Ingo Molnar wrote:
> 
> nice. Do these all get called with irqs off, all the time?

There are lots of non-irq-off cases where non-atomic counters are safe. A 
couple of reasons:

 - counters that just don't care enough. Some statistics are very 
   important to always be exact, others are "helpful" but performance is 
   more important than being exactly right.

 - counters simply not accessed (or at least changed) from interrupts at 
   all. This is very common for some cases, notably "user event" stats. 
   They may need preemption support, but nothing fancier.

 - counters that are "idempotent" wrt interrupts. For example, anything 
   that will always count up and then down again in a paired fashion 
   (think kernel lock counter, preemption counter etc) is inherently safe 
   as a per-cpu counter without needing any protection at all, since any 
   interrupts may _change_ them, but will always change them back, so even 
   if a non-atomic sequence gets interrupted, it doesn't matter.

In fact, I'd argue that for a per-cpu counter, the whole _point_ of the 
exercise is almost always performance, so locked sequences would be bad to 
assume. The fact that x86 can do "atomic" per-cpu accesses with basically 
zero cost (by virtue of it's rmw memory ops) is unusual.

Most other architectures will have a very hard time making such counters 
cheap, since for them, there "irq atomicity" (expensive irq disable or 
store conditional) or "SMP atomicity" (the same fairly expensive 
store-conditional or something even worse).

				Linus