linux: don't bring up CPUs that can never be used
PATCH 1/1 linux: don't bring up CPUs that can never be used
Without this, "nosmp" or "max_cpus=" Linux command line options are being ignored.
drivers/xen/core/smpboot.c +3 -1
@@ -253,6 +253,8 @@ void __init smp_prepare_cpus(unsigned in for_each_cpu_mask (cpu, cpu_possible_map) {if (cpu ==0 )continue ; +if (num_present_cpus () >= max_cpus) +break ;#ifdef __x86_64__ gdt_descr = &cpu_gdt_descr[cpu];
@@ -301,7 +303,7 @@ void __init smp_prepare_cpus(unsigned ininit_xenbus_allowed_cpumask ();/* Currently, Xen gives no dynamic NUMA/HT info. */ -for (cpu =1 ; cpu <NR_CPUS ; cpu++) { +for_each_present_cpu (cpu) { cpu_sibling_map[cpu] =cpumask_of_cpu (cpu); cpu_core_map[cpu] =cpumask_of_cpu (cpu); }
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines · Jan Beulich
Without this, "nosmp" or "max_cpus=" Linux command line options are being ignored.
Signed-off-by Jan Beulich <[email protected]>
I'm a little bit wary of the second hunk. Although it's probably okay, is it actually required? Looks like the first hunk is what fixes the issue.
-- Keir
Quoted 6 lines
Quoted 4 lines
Without this, "nosmp" or "max_cpus=" Linux command line options are being ignored.
Signed-off-by Jan Beulich <[email protected]>I'm a little bit wary of the second hunk. Although it's probably okay,
is it
Quoted 1 line
actually required? Looks like the first hunk is what fixes the issue.
It's probably not strictly required, but sill better than iterating over NR_CPUS, as
that is what mainline is in the process of phasing out. The only difference I can
see to the results of the original code is that for cpu 0 the two array members
now also get (re-)initialized here - but the value stored should be the same as
may have been stored earlier.
Jan
Quoted 4 lines · Jan Beulich
Quoted 1 line
I'm a little bit wary of the second hunk. Although it's probably okay,
is it
Quoted 1 line
actually required? Looks like the first hunk is what fixes the issue.
Quoted 9 lines
It's probably not strictly required, but sill better than iterating over
NR_CPUS, as
that is what mainline is in the process of phasing out. The only difference I can
see to the results of the original code is that for cpu 0 the two array members
now also get (re-)initialized here - but the value stored should be the same as
may have been stored earlier.
If it's true that those maps only get interrogated for CPUs in the cpu_online_map, could we remove that loop altogether? We initialise the map entries for CPUs as they're brought online in __cpu_up(): should that suffice?
-- Keir
Quoted 1 line
Quoted 1 line
Quoted 1 line
I'm a little bit wary of the second hunk. Although it's probably
okay,
Quoted 2 lines
Quoted 2 lines
is it
Quoted 1 line
actually required? Looks like the first hunk is what fixes the
issue.
Quoted 6 lines
Quoted 6 lines
It's probably not strictly required, but sill better than iterating over
NR_CPUS, as
that is what mainline is in the process of phasing out. The only difference I can
see to the results of the original code is that for cpu 0 the two
array
Quoted 2 lines
Quoted 2 lines
members
now also get (re-)initialized here - but the value stored should be
the
Quoted 5 lines
Quoted 2 lines
same as
may have been stored earlier.If it's true that those maps only get interrogated for CPUs in the
cpu_online_map, could we remove that loop altogether? We initialise
the map
Quoted 2 lines
entries for CPUs as they're brought online in
__cpu_up(): should that suffice?
I think considering cpu_possible_map/cpu_present_map would be safer here,
which is why I made the loop run over cpu_present_map. __cpu_up wouldn't
be sufficient for setting this up then. I am, however, not sure whether these
maps ever get accessed for non-online CPUs, so your suggestion might well
work.
Jan
Quoted 9 lines · Jan Beulich
I think considering cpu_possible_map/cpu_present_map would be safer here,
which is why I made the loop run overcpu_present_map.__cpu_upwouldn't
be sufficient for setting this up then. I am, however, not sure whether these
maps ever get accessed for non-online CPUs, so your suggestion might well
work.
x86_64 seems to leave the setup of those maps until the CPU has started running, but before setting cpu_online_map. So it should be fine for us to do the same and so delete the loop. I'll apply it separately from your patch though.
-- Keir