[PATCH v2 1/6] xen: Always calculate max_cpus value

[Jan Beulich]

>>> On 13.08.12 at 10:12, Daniel Kiper <daniel.kiper at oracle.com> wrote:
> On Fri, Aug 10, 2012 at 03:39:29PM +0100, Jan Beulich wrote:
>> >>> On 10.08.12 at 15:25, Daniel Kiper <daniel.kiper at oracle.com> wrote:
>> > max_cpus is not available since 20374 changeset (Miscellaneous data
>> > placement adjustments). It was moved to __initdata section. This section
>> > is freed after Xen initialization. Assume that max_cpus is always
>> > equal to XEN_HYPER_SIZE(cpumask_t) * 8.
>>
>> Just to repeat my response to the original version of this patch,
>> which I don't recall having got any answer from you:
>>
>> "Using nr_cpu_ids, when available, would seem a better fit. And
>>  I don't see why, on dumps from old hypervisors, you wouldn't
>>  want to continue using max_cpus. Oh, wait, I see - you would
>>  have to be able to tell whether it actually sits in .init.data, which
>>  might not be strait forward."
> 
> As I promised earlier I thought about that. The simplest way
> to do that is to check in which section max_cpus resides. There
> is some instrumentation in crash tool to do that. However, sadly
> it does not differentiate between .data and .init.data section.
> I could write something from scratch which could do that but
> I think it could have larger costs then potential gains.
> Let's leave it as is now. Current approximation is not so bad.
> However, if any opportunity appears (some functions could
> differentiate between .data and .init.data section) then
> I could fix this.

But minimally you should be using nr_cpu_ids when available.
You just have to be prepared for bits beyond that value within
any cpumask_t instance to have random contents.

Jan