On Fri, Jan 27, 2012 at 12:15:51PM -0800, Andrew Morton wrote:
> On Fri, 27 Jan 2012 10:21:36 -0600 (CST)
> Christoph Lameter <cl@xxxxxxxxx> wrote:
>
> > > +
> > > +static void readahead_stats_reset(void)
> > > +{
> > > + int i, j;
> > > +
> > > + for (i = 0; i < RA_PATTERN_ALL; i++)
> > > + for (j = 0; j < RA_ACCOUNT_MAX; j++)
> > > + percpu_counter_set(&ra_stat[i][j], 0);
> >
> > for_each_online(cpu)
> > memset(per_cpu_ptr(&ra_stat, cpu), 0, sizeof(ra_stat));
>
> for_each_possible_cpu(). And that's one reason to not open-code the
> operation. Another is so we don't have tiresome open-coded loops all
> over the place.
Amen, brother!
> But before doing either of those things we should choose boring old
> atomic_inc(). Has it been shown that the cost of doing so is
> unacceptable? Bearing this in mind:
atomics for stats in the IO path have long been known not to scale
well enough - especially now we have PCIe SSDs that can do hundreds
of thousands of reads per second if you have enough CPU concurrency
to drive them that hard. Under that sort of workload, atomics won't
scale.
>
> > The accounting code will be compiled in by default
> > (CONFIG_READAHEAD_STATS=y), and will remain inactive by default.
>
> I agree with those choices. They effectively mean that the stats will
> be a developer-only/debugger-only thing. So even if the atomic_inc()
> costs are measurable during these develop/debug sessions, is anyone
> likely to care?
I do. If I need the debugging stats, the overhead must not perturb
the behaviour I'm trying to understand/debug for them to be
useful....
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
