Re: [Xen-devel] [PATCH 02 of 10 v2] xen, libxc: introduce node maps and masks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.12.12 at 15:33, George Dunlap <george.dunlap@xxxxxxxxxxxxx> wrote:
> On 20/12/12 09:18, Jan Beulich wrote:
>>>>> On 19.12.12 at 20:07, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote:
>>> --- a/xen/include/xen/nodemask.h
>>> +++ b/xen/include/xen/nodemask.h
>>> @@ -298,6 +298,53 @@ static inline int __nodemask_parse(const
>>>   }
>>>   #endif
>>>   
>>> +/*
>>> + * nodemask_var_t: struct nodemask for stack usage.
>>> + *
>>> + * See definition of cpumask_var_t in include/xen//cpumask.h.
>>> + */
>>> +#if MAX_NUMNODES > 2 * BITS_PER_LONG
>> Is that case reasonable to expect?
> 
> 2 * BITS_PER_LONG is just going to be 128, right?  It wasn't too long 
> ago that I would have considered 4096 cores a pretty unreasonable 
> expectation.  Is there a particular reason you think this is going to be 
> more than a few years away, and a particular harm in having the code 
> here to begin with?

I just don't see node counts grow even near as quickly as core/
thread ones.

> At very least it should be replaced with something like this:
> 
> #if MAX_NUMNODES > 2 * BITS_PER_LONG
> # error "MAX_NUMNODES exceeds fixed size nodemask; need to implement 
> variable-length nodemasks"
> #endif

Yes, if there is a limitation in the code, it being violated should be
detected at build time. But I'd suppose on can construct the
statically sized mask definition such that it copes with larger counts
(just at the expense of having larger data objects perhaps
on-stack). Making sure to always pass pointers rather than objects
to functions will already eliminated a good part of the problem.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel