cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] gfs2: skip dlm_unlock calls in unmount
Date: Thu, 8 Nov 2012 10:41:58 -0500	[thread overview]
Message-ID: <20121108154158.GB25932@redhat.com> (raw)
In-Reply-To: <1352370413.2770.11.camel@menhir>

On Thu, Nov 08, 2012 at 10:26:53AM +0000, Steven Whitehouse wrote:
> Hi,
> 
> On Wed, 2012-11-07 at 14:14 -0500, David Teigland wrote:
> > When unmounting, gfs2 does a full dlm_unlock operation on every
> > cached lock.  This can create a very large amount of work and can
> > take a long time to complete.  However, the vast majority of these
> > dlm unlock operations are unnecessary because after all the unlocks
> > are done, gfs2 leaves the dlm lockspace, which automatically clears
> > the locks of the leaving node, without unlocking each one individually.
> > So, gfs2 can skip explicit dlm unlocks, and use dlm_release_lockspace to
> > remove the locks implicitly.  The one exception is when the lock's lvb is
> > being used.  In this case, dlm_unlock is called because it may update the
> > lvb of the resource.
> > 
> 
> I'm wondering just how much we are likely to gain from this.... we
> currently use LVBs for both quota (and more recently) rgrp too. If we
> were to start using the LVBs for inodes and/or iopen locks eventually
> then that would seem to rather reduce the benefits of this.

Considering what you say below, after you've converted to NL, there's no
more lvb to consider, so the lvb is not an issue in that case. The lvb is
only written if you're unlocking from PW or EX, so there's bound to always
be many unlocks that could be skipped.  I'll adjust the patch to skip
unlock unless there's an lvb and the mode is PW or EX.

> The other question is what the cost of conversion to NL vs unlock of an
> NL lock is. Even with the patch we are still iterating over each lock to
> do a conversion to NL in any case where the lock is not already in NL.
> So all we are saving is the final NL -> unlocked change.

yeah, I'd forgotten about that.

> One thought is whether it would not be better to do a direct "whatever"
> -> unlocked change in the first place, rather than splitting the
> operation into two parts.

Converting to NL would actually be less expensive than unlock because the
NL convert does not involve a reply message, but unlock does.

So skipping the unlocks is a first step that gives us a big benefit very
simply.  To benefit even further, we could later look into skipping the
"convert to NL" step also, and just abandoning the dlm locks in whatever
mode they're in; but that's probably not as simple a change.



  reply	other threads:[~2012-11-08 15:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 19:14 [Cluster-devel] gfs2: skip dlm_unlock calls in unmount David Teigland
2012-11-08 10:26 ` Steven Whitehouse
2012-11-08 15:41   ` David Teigland [this message]
2012-11-08 18:48     ` Steven Whitehouse
2012-11-08 19:59       ` David Teigland
2012-11-08 21:34         ` [Cluster-devel] [PATCH] " David Teigland
2012-11-09  9:45           ` Steven Whitehouse
2012-11-09 15:30             ` David Teigland
2012-11-12 10:44               ` Steven Whitehouse
2012-11-12 15:46                 ` David Teigland
2012-11-13 15:58           ` David Teigland
2012-11-14 10:38             ` Steven Whitehouse
2012-11-09 14:55         ` [Cluster-devel] " Steven Whitehouse

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=20121108154158.GB25932@redhat.com \
    --to=teigland@redhat.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).