Re: Locking in disk(9) api

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On May 21,  1:16pm, Thor Lancelot Simon wrote:
} On Wed, Dec 30, 2009 at 12:32:02AM +0100, Michael van Elst wrote:
} > On Tue, Dec 29, 2009 at 01:36:37PM -0800, John Nemeth wrote:
} > > } So far, all users have private locks and the disk(9) data is seen
} > > } as part of the device instance and is protected by such a private lock.
} > > } I'm not convinced that you need a separate lock just for disk(9) data.
} > > 
} > >      Aren't these the stats displayed by iostat(8) [-dDx]?  Do we need
} > > locking shared with the things that read the stats?  Or, is it
} > > considered to be okay if the reader gets stats that are in flux?
} > 
} > 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.  The system would have to be changed
to ignore obviously corrupt stats.  At which point, you might as well
not bother keeping them since they will be completely unreliable.

}-- End of excerpt from Thor Lancelot Simon