[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] sard changes for 2.5.34
In article <> 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 -

struct statctr {
unsigned long ctr;
struct statctr {
unsigned long *ctr;

struct disk_stats {
struct statctr nr_reads;

I would presume that for UP kernels,

static inline void statctr_inc(struct statctr *stctr)

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 ?

Dipankar Sarma <>
Linux Technology Center, IBM Software Lab, Bangalore, India.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.026 / U:1.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site