From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH] gfs2: skip dlm_unlock calls in unmount
Date: Fri, 9 Nov 2012 10:30:25 -0500 [thread overview]
Message-ID: <20121109153025.GA31613@redhat.com> (raw)
In-Reply-To: <1352454317.2720.1.camel@menhir>
On Fri, Nov 09, 2012 at 09:45:17AM +0000, Steven Whitehouse wrote:
> > + if (test_bit(SDF_SKIP_DLM_UNLOCK, &sdp->sd_flags) &&
> > + (!gl->gl_lvb[0] || gl->gl_state != LM_ST_EXCLUSIVE)) {
> I'm still not happy with using !gl->gl_lvb[0] to determine whether the
> LVB is in use or not. I think we need a better test, or alternatively
> just test the lock state, since most locks will be NL anyway before they
> get to this point in time,
Yeah, a glock flag indicating the lvb is used would be best, I'll just
test the lock state.
This actually brings up another improvement you could make. Right now
gfs2 enables the lvb on all locks, even though it only uses it on a small
minority. Limiting the lvb to locks that need it would:
- save 64 bytes of memory for every local lock
(32 in gfs2_glock, 32 in dlm_rsb)
- save 96 bytes of memory for every remote lock
(32 in gfs2_glock, 32 in local dlm_rsb, 32 in remote dlm_lkb)
- save 32 bytes of network message size in many dlm messages
- save a lot of memcpying of zeros
- save some recovery time
next prev parent reply other threads:[~2012-11-09 15:30 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
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 [this message]
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=20121109153025.GA31613@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).