Re: [PATCH] percpu data: only iterate over possible CPUs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> >>Oh, OK.  Ow, I don't think you want to do that.  It means that all those
> >>for_each_cpu() loops will now be iterating over all NR_CPUS cpus, whether
> >>or not they're even possible.
> >That's ok. We're mainly running under z/VM where you can attach new virtual
> >cpus on the fly to the virtual machine (up to 64 cpus).
> >The only difference to before is that it was possible to limit the waste of
> >resources by passing a number with 'maxcpus'. This value was used to generate
> >the cpu_possible_map.
> >But since the map needs to be ready when we return from setup_arch, we don't
> >have access to max_cpus, unless we parse commandline on our own...
> 
> Then it's OK to clear bits from cpu_possible_map once you have max_cpus value
> 
> for (cpu = max_cpus ; cpu < NR_CPUS ; cpu++)
> 	cpu_clear(cpu, cpu_possible_map);

Hmm... I don't think the semantics of cpu_possible_map allow to change it.
Also any code that uses for_each_cpu() may allocate memory _before_
cpu_possible_map is changed back to reflect a smaller number of cpus.
Doesn't look like the correct way to fix this.
Thinking a bit longer this was probably a reason why initialization of
this map was done in smp_prepare_cpus() before it silently moved to
setup_arch().

Heiko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux