re: Locking in disk(9) api

[matthew green <mrg%eterna.com.au@localhost>]

   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.


.mrg.