xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Andrew Jones <drjones@redhat.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>,
	Don Dutile <ddutile@redhat.com>,
	Kouya Shimura <kouya@jp.fujitsu.com>,
	Zhigang Wang <zhigang.x.wang@oracle.com>
Subject: Re: [PATCH] tools/hotplug: fix locking
Date: Tue, 26 Jun 2012 17:14:23 +0100	[thread overview]
Message-ID: <20120626161423.GV14451@redhat.com> (raw)
In-Reply-To: <1340725992.3832.159.camel@zakaz.uk.xensource.com>

On Tue, Jun 26, 2012 at 04:53:12PM +0100, Ian Campbell wrote:
> On Thu, 2012-06-21 at 13:20 +0100, Daniel P. Berrange wrote:
> > On Thu, Jun 21, 2012 at 12:49:24PM +0100, Ian Campbell wrote:
> > > I wonder if there were any followup fixes or changes, especially wrt to
> > > your point 1 above (the lack of a timeout now) requiring xend (or now
> > > libxl) changes?
> > 
> > Removing any kind of timeout was in fact the point of this change.
> > We do not want hotplug scripts stealing each others locks, or
> > timing out, because the timeouts cause alot of problems when
> > launching guests on a highly loaded machine where execution time
> > can be alot longer than a timeout setting may expect.
> 
> Agreed.
> 
> What I meant was if there was any code in xend which had inadvertently
> come to rely on the existence of the timeout which needed fixing. I'd
> guess not -- it'd be a pretty strange pattern...

It has been a while, but I don't recall any issues in the Xend
layer in this respect.

> > I expect you can't see the original BZ ticket quoted, since it
> > has customer information in it.  Here is my description of
> > what the problem we weere solving was:
> > 
> > [quote]
> > In the normal case of a single domain booting with one disk, the disk hotplug
> > script will fire once. In this case taking out the lock will never cause a sleep
> > because there's no other concurrent invocations. If a domain has 4 disks
> > configured, then the hotplug script will fire 4 times, all 4 invocations at
> > pretty much the same time. If there is even a little load on the system, the
> > locking function in the shell script will sleep for a few seconds - as many as 5
> > seconds, or potentially even time out & fail completely.
> > 
> > If say 4 or even more domains each with 4 disks start up at once, that's 16
> > invocations of the hotplug script running at once. There will be alot of sleep's
> > done & because of the very coarse 1 second granularity the delay can add up
> > significantly. 
> > 
> > The change to using flock() removes the arbitrary 1 second sleep, so the very
> > instant once hotplug script finishes, another can start & there is no repeated
> > attempts & failures to lock which would add more delay.
> > [/quote]
> 
> Thanks, this description makes sense. I'd be inclined to use it verbatim
> as the commit message.
> 
> > Usually it was our policy to send all these kind of patches upstream,
> > so I'm not really sure why this was not already merged. Possibly I
> > forgot to submit it, or maybe it was rejected - I honestly can't
> > remember.
> > 
> > Below is the original patch I wrote, to which I apply:
> > 
> >   Signed-off-by: Daniel P. Berrange.
> 
> Cheers. By my analysis the result is that the claim_lock(),
> release_lock() and _setlockfd() functions (i.e. all the actual code) are
> identical to those in the patch which Zhigang sent (the differences are
> in the removed code, which I presume has changed since you wrote the
> original patch).
> 
> Therefore I think it is appropriate to include your S-o-b on the new
> patch -- assuming you are OK with that?

Yes, that's fine with me

> 
> Also the patch is:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Ian.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

  reply	other threads:[~2012-06-26 16:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13 17:29 [PATCH] tools/hotplug: fix locking Zhigang Wang
2012-06-20 15:34 ` Ian Campbell
2012-06-20 17:53   ` Zhigang Wang
2012-06-21 11:42     ` Ian Campbell
2012-06-21 11:49       ` Ian Campbell
2012-06-21 12:08         ` Zhigang Wang
2012-06-21 12:23           ` Daniel P. Berrange
2012-06-21 13:07             ` Zhigang Wang
2012-06-21 12:20         ` Daniel P. Berrange
2012-06-26 15:53           ` Ian Campbell
2012-06-26 16:14             ` Daniel P. Berrange [this message]
2012-07-04 14:48               ` Ian Campbell
  -- strict thread matches above, loose matches on Subject: below --
2012-06-11 13:59 Zhigang Wang
2012-06-12  6:53 ` Kouya Shimura
2012-06-13  2:25   ` Marek Marczykowski
2012-06-13  8:11 ` Ian Campbell
2012-06-13  8:16   ` Zhigang Wang

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=20120626161423.GV14451@redhat.com \
    --to=berrange@redhat.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=ddutile@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kouya@jp.fujitsu.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zhigang.x.wang@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).