Re: [RFC] Scalable statistics counters using kmalloc_percpu

Rusty Russell (rusty@rustcorp.com.au)
Sat, 27 Jul 2002 14:59:04 +1000


In message <3D422553.6B126242@zip.com.au> 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.
-
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/