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

[Daniel Kiper]

On Mon, Aug 13, 2012 at 10:10:19AM +0100, Jan Beulich wrote:
> >>> 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.

I will try to improve that after my vacation (on September).

Daniel