On 28 Sep 2010, at 22:40, Tom Keiser wrote: > Any particular reason to use atomics as opposed to, say, thread-local > stats that are aggregated (non-coherently, e.g. using just atomic > reads with, perhaps, a store-to-read fence prior to the atomic reads) > on demand, a la rxkad_stats?
None at all, other than implementation simplicity. We need atomics for other counters that can't be thread local and, once we've got them, we can get get a fairly good performance improvement by switching statistics to using them. The idea of using thread local stats has already been kicked around, and it does seem to be a good direction to go in. This interface would facilitate any of these changes though, because it hides the internal statistics structure from the caller, as well as providing a point through which the kind of aggregation you suggest could be performed. Cheers, Simon. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
