[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying
On Wed, May 7, 2014 at 8:52 AM, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote: > When a cpupool is destroyed just after the last domain has been stopped the > domain might already be removed from the cpupool without having decremented > the domain count of the cpupool. This will result in rejection of the > cpupool-destroy operation. I'm a bit confused. What's the sched_move_domain() for, then? If we're going to handle "dying domains" by doing a retry, could we just get rid of it? -George > It is easy to detect this situation and to return EAGAIN in this case which > is already handled in libxc by doing a retry. > > Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> > --- > xen/common/cpupool.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c > index 4a0e569..ac833f0 100644 > --- a/xen/common/cpupool.c > +++ b/xen/common/cpupool.c > @@ -348,6 +348,8 @@ static int cpupool_unassign_cpu(struct cpupool *c, > unsigned int cpu) > cpupool0->n_dom++; > } > rcu_read_unlock(&domlist_read_lock); > + if ( (c->n_dom > 0) && !ret ) > + ret = -EAGAIN; > if ( ret ) > goto out; > } > -- > 1.7.10.4 > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |