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

[Christoph Hellwig <hch@infradead.org>]

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.