Messages in this thread | | | Date | Thu, 30 Apr 2009 09:13:44 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH] Fix dirty page accounting in redirty_page_for_writepage() |
| |
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
| |