GFS2: Don't enforce min hold time when two demotes occur in rapid succession
authorSteven Whitehouse <swhiteho@redhat.com>
Fri, 3 Sep 2010 08:39:20 +0000 (09:39 +0100)
committerSteven Whitehouse <swhiteho@redhat.com>
Mon, 20 Sep 2010 10:19:50 +0000 (11:19 +0100)
commit7b5e3d5fcf0d6fce66050bd0313a7dc2ae4abc62
tree2121e7587c5bb73faeaba6e438178ea8aff570ee
parentfe08d5a89726675a920b0e9bbbe849c46b27a6e5
GFS2: Don't enforce min hold time when two demotes occur in rapid succession

Due to the design of the VFS, it is quite usual for operations on GFS2
to consist of a lookup (requiring a shared lock) followed by an
operation requiring an exclusive lock. If a remote node has cached an
exclusive lock, then it will receive two demote events in rapid succession
firstly for a shared lock and then to unlocked. The existing min hold time
code was triggering in this case, even if the node was otherwise idle
since the state change time was being updated by the initial demote.

This patch introduces logic to skip the min hold timer in the case that
a "double demote" of this kind has occurred. The min hold timer will
still be used in all other cases.

A new glock flag is introduced which is used to keep track of whether
there have been any newly queued holders since the last glock state
change. The min hold time is only applied if the flag is set.

Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Tested-by: Abhijith Das <adas@redhat.com>
fs/gfs2/glock.c
fs/gfs2/incore.h
fs/gfs2/trace_gfs2.h