Messages in this thread | | | Date | Fri, 10 Feb 2006 03:23:32 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] percpu data: only iterate over possible CPUs |
| |
Eric Dumazet <dada1@cosmosbay.com> wrote: > > Andrew Morton a écrit : > > Andi Kleen <ak@muc.de> wrote: > >> On Thursday 09 February 2006 19:04, Andrew Morton wrote: > >>> Ashok Raj <ashok.raj@intel.com> wrote: > >>>> The problem was with ACPI just simply looking at the namespace doesnt > >>>> exactly give us an idea of how many processors are possible in this platform. > >>> We need to fix this asap - the performance penalty for HOTPLUG_CPU=y, > >>> NR_CPUS=lots will be appreciable. > >> What is this performance penalty exactly? > > > > All those for_each_cpu() loops will hit NR_CPUS cachelines instead of > > hweight(cpu_possible_map) cachelines. > > You mean NR_CPUS bits, mostly all included in a single cacheline, and even in > a single long word :) for most cases (NR_CPUS <= 32 or 64) >
No, I mean cachelines:
static void recalc_bh_state(void) { int i; int tot = 0;
if (__get_cpu_var(bh_accounting).ratelimit++ < 4096) return; __get_cpu_var(bh_accounting).ratelimit = 0; for_each_cpu(i) tot += per_cpu(bh_accounting, i).nr;
That's going to hit NR_CPUS cachelines even on a 2-way.
Or am I missing something really obvious here?
(Probably the most expensive ones will be get_page_state() and friends. And argh, they're still hardwired to CPU_MASK_ALL).
- 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/
| |