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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.05.14 at 15:05, <juergen.gross@xxxxxxxxxxxxxx> wrote:
> On 14.05.2014 14:28, Jan Beulich wrote:
>>>>> On 14.05.14 at 12:35, <juergen.gross@xxxxxxxxxxxxxx> wrote:
>>> 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...

Indeed it does. Yet - does that move have to happen in
domain_destroy()? I.e. can't it be pulled even further ahead into
domain_kill()? That one already is preemptable/resumable (via
guarantees we expect from the tools side iirc), since
domain_relinquish_resources() may take quite long a time. Of course
that'll work only if no failure condition in sched_move_domain() is
permanent.

Jan


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