Re: [Lse-tech] [patch] Scalable statistics counters with /proc reporting

From: Christoph Hellwig (
Date: Wed Aug 07 2002 - 04:02:16 EST

On Wed, Aug 07, 2002 at 02:22:27PM +0530, Ravikiran G Thirumalai wrote:
> Here's the new statctr patch (2.5.29) on top of kmalloc_percpu dynamic
> allocator. This one passes GFP_ flags for statctr_init as suggested by
> Andrew Morton and makes use of cpu_possible. Counters can be grouped into
> one or multiple /proc files as per Rik's suggestion.
> Here are the revised interfaces:
> 1. struct statctr_proc_entry
> *create_statctr_proc_entry(struct proc_dir_entry *parent, const char *name);
> To create a /proc file to group counters for automatic /proc reporting
> 2. free_statctr_proc_entry(struct statctr_proc_entry *)
> To free up the proc entry
> 3. int statctr_init(statctr_t *stctr, unsigned long val,
> struct statctr_proc_entry *pentry,
> const char *ctrname, int flags)
> Allocates memory to the counter , initialises it, and links the counter
> with statctr_proc_entry for automatic /proc reporting. ctrname is the
> counter label as it appears in /proc, flags are the GFP_ hints.
> /proc reporting can be turned off if pentry is NULL.

What about a general s/_proc//g for the API?

For statctr_init the flags argument would much better be named gfp_mask,
the val argument should be removed and the counter initialized to zero
by default - that's 90% of the uses..

Also the /proc-based implementation is really ugly. It should be moved
over to the seq_file interface at least, a simple ramfs-style own
filesystem ("stats" filesystem type) would be the cleanest solution.

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

This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:35 EST