[Cluster-devel] [GFS2 PATCH] GFS2: Instruct DLM to avoid queue convert slowdowns

Steven Whitehouse swhiteho at redhat.com
Tue Apr 10 14:46:56 UTC 2012


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.





More information about the Cluster-devel mailing list