Messages in this thread | | | Date | Wed, 7 Aug 2002 10:02:16 +0100 | From | Christoph Hellwig <> | Subject | Re: [Lse-tech] [patch] Scalable statistics counters with /proc reporting |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |