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

[Juergen Gross <juergen.gross@ts.fujitsu.com>]

On 14.05.2014 14:28, Jan Beulich wrote:
>>>> On 14.05.14 at 12:35, <juergen.gross@ts.fujitsu.com> 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@ts.fujitsu.com
Mies-van-der-Rohe-Str. 8                Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html