All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juergen Gross <juergen.gross@ts.fujitsu.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying
Date: Wed, 14 May 2014 15:22:03 +0200	[thread overview]
Message-ID: <53736DFB.8080902@ts.fujitsu.com> (raw)
In-Reply-To: <5373881302000078000122B0@mail.emea.novell.com>

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

  reply	other threads:[~2014-05-14 13:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-12 11:49 [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying Juergen Gross
2014-05-14  9:16 ` George Dunlap
2014-05-14  9:48   ` George Dunlap
2014-05-14  9:50     ` George Dunlap
2014-05-14 12:28       ` Tim Deegan
2014-05-14  9:56   ` Juergen Gross
2014-05-14 10:15     ` Jan Beulich
2014-05-14 10:19       ` George Dunlap
2014-05-14 10:35       ` Juergen Gross
2014-05-14 12:28         ` Jan Beulich
2014-05-14 13:05           ` Juergen Gross
2014-05-14 13:13             ` Jan Beulich
2014-05-14 13:22               ` Juergen Gross [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-05-07  7:52 Juergen Gross
2014-05-07 13:10 ` George Dunlap
2014-05-07 13:23   ` Juergen Gross
2014-05-08 15:10     ` George Dunlap
2014-05-09  5:01       ` Juergen Gross
2014-05-12 10:50         ` George Dunlap
2014-05-12 10:54           ` George Dunlap
2014-05-12 11:31           ` Juergen Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53736DFB.8080902@ts.fujitsu.com \
    --to=juergen.gross@ts.fujitsu.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.