From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Instruct DLM to avoid queue convert slowdowns
Date: Tue, 10 Apr 2012 15:46:56 +0100 [thread overview]
Message-ID: <1334069216.2701.23.camel@menhir> (raw)
In-Reply-To: <20120410140851.GA31555@redhat.com>
Hi,
On Tue, 2012-04-10 at 10:08 -0400, David Teigland wrote:
> On Tue, Apr 10, 2012 at 10:12:28AM +0100, Steven Whitehouse wrote:
> > Hi,
> >
> > On Thu, 2012-04-05 at 12:11 -0400, Bob Peterson wrote:
> > > Hi,
> > >
> > > Here's another patch (explanation below). This patch replies upon
> > > a DLM patch that hasn't fully gone upstream yet, so perhaps it
> > > shouldn't be added to the nmw tree until it is. This greatly
> > > improves the performance of gfs2_grow in a clustered gfs2 file system.
> > >
> > > Regards,
> > >
> > I'm still not very keen on dragging in this bit of dlm. If it is really
> > needed, then we should use the copy in the dlm itself and not add our
> > own copy of it.
>
> The table is equivalent to:
> (rq_mode > gr_mode) || (gr_mode == PR && rq_mode == CW)
>
The GLF_BLOCKING flags is almost identical to that, except that it is
also cleared on try locks. I don't think that makes any difference in
this case. Since we already distinguish between getting a new DLM lock
and conversions, it should just be a case of setting the QUECVT flag in
the conversion branch if the GLF_BLOCKING flag is set if I've understood
whats going on correctly here.
> > When you say that this relies upon this dlm patch, what does that mean?
> > What are the consequences of having this patch but not the dlm one? I'm
> > wondering whether I should hold off on this at least until the dlm one
> > has been finalised and applied.
>
> Yeah, using QUECVT everywhere will make things worse until it's fixed.
>
Ok, I'll hold off merging this (or whatever we land up with, finally)
until the DLM patch has reached a similar stage in that case,
Steve.
prev parent reply other threads:[~2012-04-10 14:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ec4f8e73-e24b-4594-991c-90245824cda7@zmail12.collab.prod.int.phx2.redhat.com>
2012-04-05 16:11 ` [Cluster-devel] [GFS2 PATCH] GFS2: Instruct DLM to avoid queue convert slowdowns Bob Peterson
2012-04-10 9:12 ` Steven Whitehouse
2012-04-10 14:01 ` Bob Peterson
2012-04-10 14:49 ` Steven Whitehouse
2012-04-10 14:08 ` David Teigland
2012-04-10 14:46 ` Steven Whitehouse [this message]
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=1334069216.2701.23.camel@menhir \
--to=swhiteho@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 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.