>>> On 10.08.12 at 15:25, Daniel Kiper <daniel.kiper(a)oracle.com&gt; 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."

>>> On 13.08.12 at 10:12, Daniel Kiper <daniel.kiper(a)oracle.com&gt; 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(a)oracle.com&gt; 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.