[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


  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
  • Date: Wed, 14 May 2014 15:22:03 +0200
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Wed, 14 May 2014 13:22:21 +0000
  • Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Organization:User-Agent: MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=qACvzq76jmZEtcXRb2TXOLUyObqI4M0K/9gM2V4UThm79JayCTx4cghB F56b+ZgLxiHPRCEQLkVI974NmrKdLEGw/IG5kyiYv4xcAnOeC0gwAiZDA aarGx1tbEsRbCB59p1Zq7pqZiON02Y/ECniLiJ5rU8Cor0h4yrWlZ9DuZ ofyrQC339uOFqUPxm4rToxvki/GmchUtKLurPWQz6VLTLYu9n5DAAkVkc dGZ//jPXDVlWZB9WTCzYuWu86KsG9;
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>

On 14.05.2014 15:13, Jan Beulich wrote:
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.

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@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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.