linux/Documentation/filesystems/gfs2-glocks.rst
<<
>>
Prefs
   1.. SPDX-License-Identifier: GPL-2.0
   2
   3============================
   4Glock internal locking rules
   5============================
   6
   7This documents the basic principles of the glock state machine
   8internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h)
   9has two main (internal) locks:
  10
  11 1. A spinlock (gl_lockref.lock) which protects the internal state such
  12    as gl_state, gl_target and the list of holders (gl_holders)
  13 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
  14    threads from making calls to the DLM, etc. at the same time. If a
  15    thread takes this lock, it must then call run_queue (usually via the
  16    workqueue) when it releases it in order to ensure any pending tasks
  17    are completed.
  18
  19The gl_holders list contains all the queued lock requests (not
  20just the holders) associated with the glock. If there are any
  21held locks, then they will be contiguous entries at the head
  22of the list. Locks are granted in strictly the order that they
  23are queued, except for those marked LM_FLAG_PRIORITY which are
  24used only during recovery, and even then only for journal locks.
  25
  26There are three lock states that users of the glock layer can request,
  27namely shared (SH), deferred (DF) and exclusive (EX). Those translate
  28to the following DLM lock modes:
  29
  30==========      ====== =====================================================
  31Glock mode      DLM    lock mode
  32==========      ====== =====================================================
  33    UN          IV/NL  Unlocked (no DLM lock associated with glock) or NL
  34    SH          PR     (Protected read)
  35    DF          CW     (Concurrent write)
  36    EX          EX     (Exclusive)
  37==========      ====== =====================================================
  38
  39Thus DF is basically a shared mode which is incompatible with the "normal"
  40shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O
  41operations. The glocks are basically a lock plus some routines which deal
  42with cache management. The following rules apply for the cache:
  43
  44==========      ==========   ==============   ==========   ==============
  45Glock mode      Cache data   Cache Metadata   Dirty Data   Dirty Metadata
  46==========      ==========   ==============   ==========   ==============
  47    UN             No              No             No            No
  48    SH             Yes             Yes            No            No
  49    DF             No              Yes            No            No
  50    EX             Yes             Yes            Yes           Yes
  51==========      ==========   ==============   ==========   ==============
  52
  53These rules are implemented using the various glock operations which
  54are defined for each type of glock. Not all types of glocks use
  55all the modes. Only inode glocks use the DF mode for example.
  56
  57Table of glock operations and per type constants:
  58
  59=============      =============================================================
  60Field              Purpose
  61=============      =============================================================
  62go_xmote_th        Called before remote state change (e.g. to sync dirty data)
  63go_xmote_bh        Called after remote state change (e.g. to refill cache)
  64go_inval           Called if remote state change requires invalidating the cache
  65go_demote_ok       Returns boolean value of whether its ok to demote a glock
  66                   (e.g. checks timeout, and that there is no cached data)
  67go_lock            Called for the first local holder of a lock
  68go_unlock          Called on the final local unlock of a lock
  69go_dump            Called to print content of object for debugfs file, or on
  70                   error to dump glock to the log.
  71go_type            The type of the glock, ``LM_TYPE_*``
  72go_callback        Called if the DLM sends a callback to drop this lock
  73go_flags           GLOF_ASPACE is set, if the glock has an address space
  74                   associated with it
  75=============      =============================================================
  76
  77The minimum hold time for each lock is the time after a remote lock
  78grant for which we ignore remote demote requests. This is in order to
  79prevent a situation where locks are being bounced around the cluster
  80from node to node with none of the nodes making any progress. This
  81tends to show up most with shared mmaped files which are being written
  82to by multiple nodes. By delaying the demotion in response to a
  83remote callback, that gives the userspace program time to make
  84some progress before the pages are unmapped.
  85
  86There is a plan to try and remove the go_lock and go_unlock callbacks
  87if possible, in order to try and speed up the fast path though the locking.
  88Also, eventually we hope to make the glock "EX" mode locally shared
  89such that any local locking will be done with the i_mutex as required
  90rather than via the glock.
  91
  92Locking rules for glock operations:
  93
  94=============    ======================    =============================
  95Operation        GLF_LOCK bit lock held    gl_lockref.lock spinlock held
  96=============    ======================    =============================
  97go_xmote_th           Yes                       No
  98go_xmote_bh           Yes                       No
  99go_inval              Yes                       No
 100go_demote_ok          Sometimes                 Yes
 101go_lock               Yes                       No
 102go_unlock             Yes                       No
 103go_dump               Sometimes                 Yes
 104go_callback           Sometimes (N/A)           Yes
 105=============    ======================    =============================
 106
 107.. Note::
 108
 109   Operations must not drop either the bit lock or the spinlock
 110   if its held on entry. go_dump and do_demote_ok must never block.
 111   Note that go_dump will only be called if the glock's state
 112   indicates that it is caching uptodate data.
 113
 114Glock locking order within GFS2:
 115
 116 1. i_rwsem (if required)
 117 2. Rename glock (for rename only)
 118 3. Inode glock(s)
 119    (Parents before children, inodes at "same level" with same parent in
 120    lock number order)
 121 4. Rgrp glock(s) (for (de)allocation operations)
 122 5. Transaction glock (via gfs2_trans_begin) for non-read operations
 123 6. i_rw_mutex (if required)
 124 7. Page lock  (always last, very important!)
 125
 126There are two glocks per inode. One deals with access to the inode
 127itself (locking order as above), and the other, known as the iopen
 128glock is used in conjunction with the i_nlink field in the inode to
 129determine the lifetime of the inode in question. Locking of inodes
 130is on a per-inode basis. Locking of rgrps is on a per rgrp basis.
 131In general we prefer to lock local locks prior to cluster locks.
 132
 133Glock Statistics
 134----------------
 135
 136The stats are divided into two sets: those relating to the
 137super block and those relating to an individual glock. The
 138super block stats are done on a per cpu basis in order to
 139try and reduce the overhead of gathering them. They are also
 140further divided by glock type. All timings are in nanoseconds.
 141
 142In the case of both the super block and glock statistics,
 143the same information is gathered in each case. The super
 144block timing statistics are used to provide default values for
 145the glock timing statistics, so that newly created glocks
 146should have, as far as possible, a sensible starting point.
 147The per-glock counters are initialised to zero when the
 148glock is created. The per-glock statistics are lost when
 149the glock is ejected from memory.
 150
 151The statistics are divided into three pairs of mean and
 152variance, plus two counters. The mean/variance pairs are
 153smoothed exponential estimates and the algorithm used is
 154one which will be very familiar to those used to calculation
 155of round trip times in network code. See "TCP/IP Illustrated,
 156Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement",
 157p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards.
 158Unlike the TCP/IP Illustrated case, the mean and variance are
 159not scaled, but are in units of integer nanoseconds.
 160
 161The three pairs of mean/variance measure the following
 162things:
 163
 164 1. DLM lock time (non-blocking requests)
 165 2. DLM lock time (blocking requests)
 166 3. Inter-request time (again to the DLM)
 167
 168A non-blocking request is one which will complete right
 169away, whatever the state of the DLM lock in question. That
 170currently means any requests when (a) the current state of
 171the lock is exclusive, i.e. a lock demotion (b) the requested
 172state is either null or unlocked (again, a demotion) or (c) the
 173"try lock" flag is set. A blocking request covers all the other
 174lock requests.
 175
 176There are two counters. The first is there primarily to show
 177how many lock requests have been made, and thus how much data
 178has gone into the mean/variance calculations. The other counter
 179is counting queuing of holders at the top layer of the glock
 180code. Hopefully that number will be a lot larger than the number
 181of dlm lock requests issued.
 182
 183So why gather these statistics? There are several reasons
 184we'd like to get a better idea of these timings:
 185
 1861. To be able to better set the glock "min hold time"
 1872. To spot performance issues more easily
 1883. To improve the algorithm for selecting resource groups for
 189   allocation (to base it on lock wait time, rather than blindly
 190   using a "try lock")
 191
 192Due to the smoothing action of the updates, a step change in
 193some input quantity being sampled will only fully be taken
 194into account after 8 samples (or 4 for the variance) and this
 195needs to be carefully considered when interpreting the
 196results.
 197
 198Knowing both the time it takes a lock request to complete and
 199the average time between lock requests for a glock means we
 200can compute the total percentage of the time for which the
 201node is able to use a glock vs. time that the rest of the
 202cluster has its share. That will be very useful when setting
 203the lock min hold time.
 204
 205Great care has been taken to ensure that we
 206measure exactly the quantities that we want, as accurately
 207as possible. There are always inaccuracies in any
 208measuring system, but I hope this is as accurate as we
 209can reasonably make it.
 210
 211Per sb stats can be found here::
 212
 213    /sys/kernel/debug/gfs2/<fsname>/sbstats
 214
 215Per glock stats can be found here::
 216
 217    /sys/kernel/debug/gfs2/<fsname>/glstats
 218
 219Assuming that debugfs is mounted on /sys/kernel/debug and also
 220that <fsname> is replaced with the name of the gfs2 filesystem
 221in question.
 222
 223The abbreviations used in the output as are follows:
 224
 225=========  ================================================================
 226srtt       Smoothed round trip time for non blocking dlm requests
 227srttvar    Variance estimate for srtt
 228srttb      Smoothed round trip time for (potentially) blocking dlm requests
 229srttvarb   Variance estimate for srttb
 230sirt       Smoothed inter request time (for dlm requests)
 231sirtvar    Variance estimate for sirt
 232dlm        Number of dlm requests made (dcnt in glstats file)
 233queue      Number of glock requests queued (qcnt in glstats file)
 234=========  ================================================================
 235
 236The sbstats file contains a set of these stats for each glock type (so 8 lines
 237for each type) and for each cpu (one column per cpu). The glstats file contains
 238a set of these stats for each glock in a similar format to the glocks file, but
 239using the format mean/variance for each of the timing stats.
 240
 241The gfs2_glock_lock_time tracepoint prints out the current values of the stats
 242for the glock in question, along with some addition information on each dlm
 243reply that is received:
 244
 245======   =======================================
 246status   The status of the dlm request
 247flags    The dlm request flags
 248tdiff    The time taken by this specific request
 249======   =======================================
 250
 251(remaining fields as per above list)
 252
 253
 254