On Wed, Dec 21, 2011 at 09:29:36AM +0800, Wu Fengguang wrote: > On Tue, Dec 20, 2011 at 12:32:41AM +0800, Jan Kara wrote: > > On Wed 14-12-11 14:36:25, Wu Fengguang wrote: > > > > This looks all inherently racy (which doesn't matter much as you suggest) > > > > so I just wanted to suggest that if you used per-cpu counters you'd get > > > > race-free and faster code at the cost of larger data structures and using > > > > percpu_counter_add() instead of ++ (which doesn't seem like a big > > > > complication to me). > > > > > > OK, here is the incremental patch to use per-cpu counters :) > > Thanks! This looks better. I just thought you would use per-cpu counters > > as defined in include/linux/percpu_counter.h and are used e.g. by bdi > > stats. This is more standard for statistics in the kernel than using > > per-cpu variables directly. > > Ah yes, I overlooked that facility! However the percpu_counter's > ability to maintain and quickly retrieve the global value seems > unnecessary feature/overheads for readahead stats, because here we > only need to sum up the global value when the user requests it. If > switching to percpu_counter, I'm afraid every readahead(1MB) event > will lead to the update of percpu_counter global value (grabbing the > spinlock) due to 1MB > some small batch size. This actually performs > worse than the plain global array of values in the v1 patch. So use a custom batch size so that typical increments don't require locking for every add. The bdi stat counters are an example of this sort of setup to reduce lock contention on typical IO workloads as concurrency increases. All these stats have is a requirement for a different batch size to avoid frequent lock grabs. The stats don't have to update the global counter very often (only to prvent overflow!) so you count get away with a batch size in the order of 2^30 without any issues.... We have a general per-cpu counter infrastructure - we should be using it and improving it and not reinventing it a different way every time we need a per-cpu counter. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
