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
