From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying Date: Wed, 14 May 2014 15:22:03 +0200 Message-ID: <53736DFB.8080902@ts.fujitsu.com> References: <1399895385-18894-1-git-send-email-juergen.gross@ts.fujitsu.com> <53733DE5.9060406@ts.fujitsu.com> <53735E690200007800012106@mail.emea.novell.com> <537346DB.9070009@ts.fujitsu.com> <53737D900200007800012238@mail.emea.novell.com> <53736A2F.9060103@ts.fujitsu.com> <5373881302000078000122B0@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5373881302000078000122B0@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 14.05.2014 15:13, Jan Beulich wrote: >>>> On 14.05.14 at 15:05, wrote: >> On 14.05.2014 14:28, Jan Beulich wrote: >>>>>> On 14.05.14 at 12:35, 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. Aah, excellent! Now the patch seems to be very simple! I'll do some tests to verify it isn't breaking something. 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