[Cluster-devel] [PATCH] gfs2: skip dlm_unlock calls in unmount

[David Teigland <teigland@redhat.com>]

On Mon, Nov 12, 2012 at 10:44:36AM +0000, Steven Whitehouse wrote:
> > - 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
> > 
> > 
> 
> Yes, although we did consider what the best thing to do was back at the
> start of GFS2 development wrt LVBs. The actual overhead didn't seem too
> much really. The previous implementation had the LVB hanging off the
> glock from a pointer, so on 64 bit, that pointer alone was 8 bytes. We
> also saved another 4 bytes (plus a further 4 for alignment) by not
> requiring the atomic counter. So it seemed not unreasonable to just
> inline the LVB into the glock.

I still think you'll save around 64-80 bytes per lock on average.

> Another for having it on all glocks was that if we did want to start
> making use of it on different glock types in the future, we could do so
> without having to worry about whether its value would be preserved or
> not. Also, it removed some tests from the fast path of acquiring and
> dropping locks.

Keep in mind that the dlm does not inline them, so using an lvb when it's
not needed creates extra work in the dlm.  This extra work probably
exceeds the extra work gfs2 would have to do with non-inlined lvbs.

> Trying to reduce the size of the lock requests makes sense if that is
> becoming a limiting factor in performance (is it? I'm not sure) so maybe
> we should revisit this.

I think it's worth a try, it's probably no less helpful than a lot of the
other optimizations we've added, which do add up together.