Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 21 Dec 2011 09:29:36 +0800 | From | Wu Fengguang <> | Subject | Re: [PATCH 6/9] readahead: add /debug/readahead/stats |
| |
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.
Thanks, Fengguang
| ![\](/images/icornerr.gif) |