On Mon, Jul 29, 2002 at 11:23:06AM -0700, Andrew Morton wrote:
> Ravikiran G Thirumalai wrote:
> >
> > ...
> >
> > > General comment: we need to clean up the kernel_stat stuff. We
> > > cannot just make it per-cpu because it is 32k in size already. I
> > > would suggest that we should break out the disk accounting and
> > > make the rest of kernel_stat per CPU.
> > >
> > > That would be a great application of your interface, and a good
> > > way to get your interface merged ;) Is that something which you
> > > have time to do?
> >
> > Sure,... anything to get these interfaces merged :)
>
> Well Rusty's point about just using the percpu API seemed
> reasonable - that's basically equivalent to statically defining
> the data. In what situation is dynamic allocation needed?
>
> Well, in modules for one. Unless we work out a way to make the
> percpu API work with storage which is defined within modules.
Apart from modules, I can see two advantages -
1. static per_cpu data has to be allocated based on NR_CPUS because
of the current offset calculations. kmalloc_percpu() needs to allocate only
for cpu_possible() cpus.
2. If the statistics is a part of a dynamically allocated structure.
Thanks
-- Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net 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 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/
This archive was generated by hypermail 2b29 : Tue Jul 30 2002 - 14:00:33 EST