Re: [Xen-devel] [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying

[Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>]

On 14.05.2014 14:28, Jan Beulich wrote:
> > > > On 14.05.14 at 12:35, <juergen.gross@xxxxxxxxxxxxxx> wrote:
> > On 14.05.2014 12:15, Jan Beulich wrote:
> > > What prevents cpupool_rm_domain() getting moved from
> > > complete_domain_destroy() to domain_destroy(), before the
> > > domain gets taken off the list? I actually assume that there are
> > > more things here that may not really need deferring until the
> > > last possible moment...
> > sched_destroy_vcpu() and sched_destroy_domain() have to happen before
> > cpupool_rm_domain(). This could be avoided if the domain would be moved to
> > cpupool0 in domain_destroy().
> >
> > Hmm, doesn't sound too bad. This would be just symmetrical to domain
> > creation. What do you think?
> I'm always in favor of symmetry, where possible and suitable. So
> unless George objects or sees problems with this, why don't you
> give this a try?
One problem arises: sched_move_domain() can fail. Is there a preferred way to
handle this situation in domain_destroy() ? I could try to defer destroying
the domain until sched_move_domain() succeeds, but using a busy loop doing this
seems contra-productive and a timer based solution requires a timer structure.

I could reuse the domain watchdog_timer entries if I move
watchdog_domain_destroy() to domain_destroy() (which seems to be not critical).

OTOH this seems a little bit hacky...


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
PSO PM&D ES&S SWE OS6                  Telephone: +49 (0) 89 62060 2932
Fujitsu                                   e-mail: juergen.gross@xxxxxxxxxxxxxx
Mies-van-der-Rohe-Str. 8                Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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