[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 02 of 10 v2] xen, libxc: introduce node maps and masks
>>> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |