Re: [RFC] Scalable statistics counters using kmalloc_percpu

[Andrew Morton <akpm@zip.com.au>]

Rusty Russell wrote:
> 
> > > +       for( i=0; i < NR_CPUS; i++ )
> > > +               res += *per_cpu_ptr(stctr->ctr, i);
> > > +       return res;
> > > +}
> >
> > Oh dear.  Most people only have two CPUs.
> >
> > Rusty, can we *please* fix this?  Really soon?
> 
> Linus just applied the hotplug cpu boot patch in bk, which gives
> cpu_possible(i), for exactly this purpose.

Good.  And will it be possible to iterate across all CPUs
without having to iterate across NR_CPUS?

> > 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.
> 
> kernel_stat is dynamically allocated???

No.  It's jut a big lump of bss.
 
> Personally, I think that dynamically allocated per-cpu datastructures,
> like dynamically-allocated brlocks, are something we might need
> eventually, but look at what a certain driver did with the "make it
> per-cpu" concept already.  I don't want to rush in that direction.

What driver is that?

And no, we need to do something about the NR_CPUS bloat Right Now.

In my build there is a quarter megabyte of per cpu data.  And that
does not include the (currently small) .data.percpu * 32.

The is pretty much entirely wasted memory, and it will only get
worse. Making NR_CPUS compile-time configurable is a lame solution.
Wasting the memory is out of the question.

Dynamic allocation is the only thing left, yes?

-