From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Tue, 10 Apr 2012 15:46:56 +0100 Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Instruct DLM to avoid queue convert slowdowns In-Reply-To: <20120410140851.GA31555@redhat.com> References: <1334049148.2701.6.camel@menhir> <20120410140851.GA31555@redhat.com> Message-ID: <1334069216.2701.23.camel@menhir> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.