Messages in this thread | | | Date | Thu, 13 Jul 2006 01:00:04 -0700 | From | Andrew Morton <> | Subject | Re: [Patch] statistics infrastructure - update 10 |
| |
On Wed, 12 Jul 2006 18:45:08 +0200 Martin Peschke <mp3@de.ibm.com> wrote:
> On Wed, 2006-07-12 at 09:10 -0700, Andrew Morton wrote: > > On Wed, 12 Jul 2006 14:27:39 +0200 > > Martin Peschke <mp3@de.ibm.com> wrote: > > > > > +#define statistic_ptr(stat, cpu) \ > > > + ((struct percpu_data*)((stat)->data))->ptrs[(cpu)] > > > > This would be the only part of the kernel which uses percpu_data directly - > > everything else uses the APIs (ie: per_cpu_ptr()). How come? > > The API, i.e. per_cpu_ptr(), doesn't allow to assign a value to any of > the pointers in struct percpu_data. I need that capability because I > make use of cpu hotplug notifications to fix per-cpu data at run time.
Fair enough, I guess.
> With regard to memory footprint this is much more efficient than using > alloc_percpu().
How much storage are we talking about here? I find it a bit hard to work that out.
> Is it be preferable to add something like set_per_cpu_ptr() to the API?
hm. Add a generic extension to a generic interface within a specific subsystem versus doing it generically. Hard call ;)
I'd suggest that you:
- Create a new __alloc_percpu_mask(size_t size, cpumask_t cpus)
- Make that function use your newly added
percpu_data_populate(struct percpu_data *p, int cpu, size_t size, gfp_t gfp);
(maybe put `size' into 'struct percpu_data'?)
- implement __alloc_percpu() as __alloc_percpu_mask(size, cpu_possible_map)
- hack around madly until it compiles on uniprocessor. - 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/
| |