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 :|
next prev parent 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 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.