lkml.org 
[lkml]   [2009]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-04-30 18:25    [W:0.075 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site