Re: [RFC][PATCH] sard changes for 2.5.34

[Dipankar Sarma <dipankar@in.ibm.com>]

In article <3D80EE1D.34AF4FF2@digeo.com> Andrew Morton wrote:
> Rick Lindsley wrote:
>> Regardless of which route we go, can you suggest a good exercise to
>> demonstrate the advantage of per-cpu counters?  It seems intuitive to
>> me, but I'm much more comfortable when I have numbers to back me up.

> I don't think this is enough to justify a new subsystem like
> statctr_t (struct statctr, please).

statctr_t was originally used to hide the fact that in UP kernels
it reduces to unsigned long. But I think that was not necessary -

#ifdef CONFIG_SMP
struct statctr {
	unsigned long ctr;
};
#else
struct statctr {
	unsigned long *ctr;
};
#endif

struct disk_stats {
	....
	....
	struct statctr nr_reads;
};

I would presume that for UP kernels,

static inline void statctr_inc(struct statctr *stctr)
{
	(stctr->ctr)++;
}

statctr_inc(&disk_stats.nr_reads) would generate the same code
as diskstats.nr_reads++; We will verify this and remove statctr_t.

I think justifying statctrs based on numbers from one single usage will
likely be difficult. Our measurements (e.g. net_device_stats and
cache event profiling with kernprof) showed that while cache misses
in those routines are reduced significantly, it isn't enough to make
an impact in the benchmark throughput. We need to adopt statctrs
in many subsystems. Perhaps that will show some benefits specially
on higher-end hardware (16CPU+).

Since we are beginning to run linux on such hardware, why not adopt a simple
framework now ?

Thanks
-- 
Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.