Xen devel - Aug 2006 - [PATCH] linux: don''t bring up CPUs that can never be used

Without this, "nosmp" or "max_cpus=" Linux command line
options are
being ignored.

Signed-off-by: Jan Beulich <jbeulich@novell.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14/8/06 2:01 pm, "Jan Beulich" <jbeulich@novell.com> wrote:
> Without this, "nosmp" or "max_cpus=" Linux command line
options are
> being ignored.
> 
> Signed-off-by: Jan Beulich <jbeulich@novell.com>
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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>> Without this, "nosmp" or "max_cpus=" Linux command
line options are
>> being ignored.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@novell.com>
>
>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.
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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14/8/06 2:23 pm, "Jan Beulich" <jbeulich@novell.com> wrote:
>> 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.
> 
> 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



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

>>> 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.
>> 
>> 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?
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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 14/8/06 3:05 pm, "Jan Beulich" <jbeulich@novell.com> wrote:
> 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.
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
 



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel