lkml.org 
[lkml]   [2006]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] percpu data: only iterate over possible CPUs
Andrew Morton wrote:
> Eric Dumazet <dada1@cosmosbay.com> wrote:
> >
> > Andrew Morton a écrit :
> > > Andrew Morton <akpm@osdl.org> wrote:
> > >> Users of __GENERIC_PER_CPU definitely need cpu_possible_map to be initialised
> > >> by the time setup_per_cpu_areas() is called,
> > >
> > > err, they'll need it once Eric's
> > > dont-waste-percpu-memory-on-not-possible-CPUs patch is merged..
> > >
> > >> so I think it makes sense to
> > >> say "thou shalt initialise cpu_possible_map in setup_arch()".
> > >>
> > >> I guess Xen isn't doing that. Can it be made to?
> > >
> > > Lame fix: cpu_possible_map = (1<<NR_CPUS)-1 in setup_arch().
> >
> > I dont understand why this HOTPLUG stuff is problematic for Xen (or other
> > arch) : If CONFIG_HOTPLUG_CPU is configured, then the map should be preset to
> > CPU_MASK_ALL.
>
> Presumably not all architectures are doing that.

powerpc/ppc64, for instance, determines the number of possible cpus
from information exported by firmware (and I'm mystified as to why
other platforms don't do this). So it's typical to have a kernel an a
pSeries partition with NR_CPUS=128, but cpu_possible_map = 0xff.


> > Its even documented in line 332 of include/linux/cpumask.h
> >
> > * #ifdef CONFIG_HOTPLUG_CPU
> > * cpu_possible_map - all NR_CPUS bits set
>
> That seems a quite bad idea. If we know which CPUs are possible we should
> populate cpu_possible_map correctly, whether or not CONFIG_HOTPLUG_CPU is
> set. Setting all the bits like that wastes memory and wastes CPU cycles.

Yes, that comment is wrong or outdated.

-
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/

\
 
 \ /
  Last update: 2006-02-09 17:11    [W:0.115 / U:0.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site