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?
-
-
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:26 EST