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/