[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2 of 3] switch to dynamically allocated cpumask in domain_update_node_affinity()



On Tue, 2012-01-24 at 09:56 +0000, Juergen Gross wrote:
> On 01/24/2012 10:33 AM, Ian Campbell wrote:
> > On Tue, 2012-01-24 at 05:54 +0000, Juergen Gross wrote:
> >> # HG changeset patch
> >> # User Juergen Gross<juergen.gross@xxxxxxxxxxxxxx>
> >> # Date 1327384410 -3600
> >> # Node ID 08232960ff4bed750d26e5f1ff53972fee9e0130
> >> # Parent  99f98e501f226825fbf16f6210b4b7834dff5df1
> >> switch to dynamically allocated cpumask in
> >> domain_update_node_affinity()
> >>
> >> cpumasks should rather be allocated dynamically.
> >>
> >> Signed-off-by: juergen.gross@xxxxxxxxxxxxxx
> >>
> >> diff -r 99f98e501f22 -r 08232960ff4b xen/common/domain.c
> >> --- a/xen/common/domain.c       Tue Jan 24 06:53:06 2012 +0100
> >> +++ b/xen/common/domain.c       Tue Jan 24 06:53:30 2012 +0100
> >> @@ -333,23 +333,27 @@ struct domain *domain_create(
> >>
> >>   void domain_update_node_affinity(struct domain *d)
> >>   {
> >> -    cpumask_t cpumask;
> >> +    cpumask_var_t cpumask;
> >>       nodemask_t nodemask = NODE_MASK_NONE;
> >>       struct vcpu *v;
> >>       unsigned int node;
> >>
> >> -    cpumask_clear(&cpumask);
> >> +    if ( !zalloc_cpumask_var(&cpumask) )
> >> +        return;
> > If this ends up always failing we will never set node_affinity to
> > anything at all. Granted that is already a pretty nasty situation to be
> > in but perhaps setting the affinity to NODE_MASK_ALL on failure is
> > slightly more robust?
> 
> Hmm, I really don't know.
> 
> node_affinity is only used in alloc_heap_pages(), which will fall back to 
> other
> nodes if no memory is found on those nodes.
> 
> OTOH this implementation might change in the future.
> 
> The question is whether node_affinity should rather contain a subset or a
> superset of the nodes the domain is running on.

If we've had an allocation failure then we are presumably unable to
calculate whether anything is a sub/super set other than the trivial all
nodes or no nodes cases. IMHO no nodes is likely to lead to
strange/unexpected behaviour so all nodes is safer.
 
> What should be done if allocating a cpumask fails later? Should node_affinity
> be set to NODE_MASK_ALL/NONE or should it be left untouched assuming a real
> change is a rare thing to happen?

Leaving alone seems reasonable and it would mean this issue could be
fixed by simply initialising d->node_affinity to all nodes on allocation
instead of worrying about it here.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.