All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jim Fehlig <jfehlig@suse.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 0/3] libxl: domain destroy fixes
Date: Fri, 27 Mar 2015 14:16:48 -0400	[thread overview]
Message-ID: <20150327181648.GA2475@l.oracle.com> (raw)
In-Reply-To: <1427314116-14451-1-git-send-email-jfehlig@suse.com>

On Wed, Mar 25, 2015 at 02:08:33PM -0600, Jim Fehlig wrote:
> This small series of patches fixes some issues wrt domain destroy in
> the libxl driver.  The primary motivation for this work is to
> prevent locking the virDomainObj during long running destroy operations
> on large memory domains.
> 
> Patch 1 moves job acquisition from libxlDomainStart to it's callers so
> they have more control over when the job is acquired.  Patch 2 fixes a
> few spots where we never acquired a job during domain destroy.  Patch 3
> contains the interesting change, where the virDomainObj is unlocked
> during the long-running destroy operation.
> 
> This series wraps up my work to improve parallel OpenStack Tempest runs
> against the libxl driver.  With libvirt.git master + this series + a
> patched libxl [1], I've successfully run a reproducer that was hitting
> the same issues encountered by Tempest.
> 
> [1] libxl commits from xen.git: 93699882d, f1335f0d, 4783c99a, 1c91d6fba,
> and 188e9c54.  I'll contact the stable branch maintainers and ask them
> to include these commits in the next Xen 4.4.x and 4.5.x releases.
> 
> Jim Fehlig (3):
>   libxl: Move job acquisition in libxlDomainStart to callers
>   libxl: acquire a job when destroying a domain
>   libxl: drop virDomainObj lock when destroying a domain

I am no expert at this- but I dug through the code to understand how
the job and locking is done and now I am more comfortable with it.

Since I am new to this I went through all of the the callsites (which used
the job now) from the driver to make sure that there are no chained calls
(one function calling another which also uses a mutex or job locking).

I only found one culprit (libxlDomainAutoCoreDump being called from
 libxlDomainShutdownThread).

Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
>  src/libxl/libxl_domain.c | 77 +++++++++++++++++++----------------------------
>  src/libxl/libxl_domain.h |  4 ---
>  src/libxl/libxl_driver.c | 78 ++++++++++++++++++++++++++++++++++++------------
>  3 files changed, 89 insertions(+), 70 deletions(-)
> 
> -- 
> 1.8.4.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  parent reply	other threads:[~2015-03-27 18:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1427314116-14451-1-git-send-email-jfehlig@suse.com>
2015-03-25 20:08 ` [PATCH 1/3] libxl: Move job acquisition in libxlDomainStart to callers Jim Fehlig
2015-04-01  9:55   ` [libvirt] " Martin Kletzander
2015-04-01 17:29     ` Jim Fehlig
2015-03-25 20:08 ` [PATCH 2/3] libxl: acquire a job when destroying a domain Jim Fehlig
2015-03-25 20:08 ` [PATCH 3/3] libxl: drop virDomainObj lock " Jim Fehlig
2015-03-26 15:14   ` Ian Campbell
     [not found]   ` <1427382869.13935.61.camel@citrix.com>
2015-03-26 23:16     ` Jim Fehlig
     [not found] ` <1427314116-14451-3-git-send-email-jfehlig@suse.com>
2015-03-26  1:32   ` [PATCH 2/3] libxl: acquire a job " Konrad Rzeszutek Wilk
     [not found]   ` <20150326013242.GA8605@konrad-lan.dumpdata.com>
2015-03-26 21:29     ` Jim Fehlig
     [not found]     ` <55147A4F.2000903@suse.com>
2015-04-01 10:12       ` [libvirt] " Martin Kletzander
     [not found]       ` <20150401101205.GC30610@wheatley>
2015-04-01 21:37         ` Jim Fehlig
2015-03-27 18:16 ` Konrad Rzeszutek Wilk [this message]
2015-03-27 18:34   ` [PATCH 0/3] libxl: domain destroy fixes Jim Fehlig
     [not found]   ` <5515A29C.5040802@suse.com>
2015-03-30 19:13     ` Jim Fehlig
2015-03-30 14:00 ` Anthony PERARD
2015-03-25 20:08 Jim Fehlig

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=20150327181648.GA2475@l.oracle.com \
    --to=konrad.wilk@oracle.com \
    --cc=jfehlig@suse.com \
    --cc=libvir-list@redhat.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.