[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
re: Locking in disk(9) api
On Tue, Dec 29, 2009 at 03:53:58PM -0800, John Nemeth wrote:
> On May 21, 1:16pm, Thor Lancelot Simon wrote:
> } On Wed, Dec 30, 2009 at 12:32:02AM +0100, Michael van Elst wrote:
> } >
> } > Well, originally this was read via kvm and always in a state of flux.
> } I think this is almost the canonical example of data we should not lock.
> } The cost of using locking *or* atomic operations for statistics update
> } will be extreme on busy MP systems, and there's almost no real benefit.
> In the case in question the real benefit is avoiding a panic when
> dk_stats->io_busy goes negative.
If the system can panic because a "statistic" goes negative, that's
a plenty serious bug all its own.
If we can't figure out how to choose appropriate size and signedness
for statistics so the kernel can update them unlocked with, at worst,
a risk that readers will see a slightly outdated value, we're a lot
dumber than I think we are.
the size and sign are irrelevant for this check (it actually checks
against zero, not negative.)
since i don't think that completely corrupting the "total bytes
transferred" of iostats is an OK thing to do, i don't agree here that
we have a normal case to play fast&loose with stats. our drivers
should ensure they call disk_*busy() with appropriate locking. ie,
this isn't some transient failure, it's going to potentially corrupt
"since boot" data every time the subsystem is pushed hard.
Main Index |
Thread Index |