From: Rusty R. <ru...@ru...> - 2002-07-27 01:57:24
|
> > + 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. > 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??? 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. Cheers, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. |
From: Andrew M. <ak...@zi...> - 2002-07-27 04:37:01
|
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? - |
From: Rusty R. <ru...@ru...> - 2002-07-27 05:24:13
|
In message <3D4...@zi...> you write: > Good. And will it be possible to iterate across all CPUs > without having to iterate across NR_CPUS? Hmm, define *all cpus* please? All online cpus? All possible CPUs? Interface discussed with DaveM was: first_cpu(), next_cpu(cpu), which covers online CPUs, and gives a nice interface for things like irq balancers which want to snarf the next online cpu. Like it? > > 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? NTFS. > 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? Um, no! Here is the plan: 1) change per-cpu data to only allocate data for cpus where cpu_possible(i) (add cache coloring and NUMA allocation as desired). 2) Convert non-modular cases to use per-cpu data (once the interface changes again, <SIGH>). We'll end up using *less* memory than before. We're just doing it in easy stages. Feel better now? Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. |
From: Andrew M. <ak...@zi...> - 2002-07-27 06:08:19
|
Rusty Russell wrote: > > In message <3D4...@zi...> you write: > > Good. And will it be possible to iterate across all CPUs > > without having to iterate across NR_CPUS? > > Hmm, define *all cpus* please? All online cpus? All possible CPUs? All possible. > Interface discussed with DaveM was: first_cpu(), next_cpu(cpu), which > covers online CPUs, and gives a nice interface for things like irq > balancers which want to snarf the next online cpu. > > Like it? for (cpu = first_cpu(); cpu != (what?); cpu = next_cpu(cpu)) that'll work. > ... > > > 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? > > Um, no! Here is the plan: > > 1) change per-cpu data to only allocate data for cpus where > cpu_possible(i) (add cache coloring and NUMA allocation as desired). > > 2) Convert non-modular cases to use per-cpu data (once the interface > changes again, <SIGH>). > > We'll end up using *less* memory than before. We're just doing it in > easy stages. > > Feel better now? Yup. - |