From: Andreas Gruenbacher <agruenba@redhat.com>
To: gfs2@lists.linux.dev
Cc: Andreas Gruenbacher <agruenba@redhat.com>
Subject: [PATCH 07/15] gfs2: Update glocks documentation
Date: Wed, 29 May 2024 19:03:44 +0200 [thread overview]
Message-ID: <20240529170352.571141-8-agruenba@redhat.com> (raw)
In-Reply-To: <20240529170352.571141-1-agruenba@redhat.com>
Rearrange the table of locking modes and associated caching capability
to be in order of increasing caching capability.
Update the description of the glock operations.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
---
Documentation/filesystems/gfs2-glocks.rst | 52 +++++++++++------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/Documentation/filesystems/gfs2-glocks.rst b/Documentation/filesystems/gfs2-glocks.rst
index 8a5842929b60..17ce3413608a 100644
--- a/Documentation/filesystems/gfs2-glocks.rst
+++ b/Documentation/filesystems/gfs2-glocks.rst
@@ -40,14 +40,14 @@ shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O
operations. The glocks are basically a lock plus some routines which deal
with cache management. The following rules apply for the cache:
-========== ========== ============== ========== ==============
-Glock mode Cache data Cache Metadata Dirty Data Dirty Metadata
-========== ========== ============== ========== ==============
- UN No No No No
- SH Yes Yes No No
- DF No Yes No No
- EX Yes Yes Yes Yes
-========== ========== ============== ========== ==============
+========== ============== ========== ========== ==============
+Glock mode Cache Metadata Cache data Dirty Data Dirty Metadata
+========== ============== ========== ========== ==============
+ UN No No No No
+ DF Yes No No No
+ SH Yes Yes No No
+ EX Yes Yes Yes Yes
+========== ============== ========== ========== ==============
These rules are implemented using the various glock operations which
are defined for each type of glock. Not all types of glocks use
@@ -55,23 +55,24 @@ all the modes. Only inode glocks use the DF mode for example.
Table of glock operations and per type constants:
-============= =============================================================
+============== =============================================================
Field Purpose
-============= =============================================================
-go_xmote_th Called before remote state change (e.g. to sync dirty data)
+============== =============================================================
+go_sync Called before remote state change (e.g. to sync dirty data)
go_xmote_bh Called after remote state change (e.g. to refill cache)
go_inval Called if remote state change requires invalidating the cache
go_demote_ok Returns boolean value of whether its ok to demote a glock
(e.g. checks timeout, and that there is no cached data)
-go_lock Called for the first local holder of a lock
-go_unlock Called on the final local unlock of a lock
+go_instantiate Called when a glock has been acquired
+go_held Called every time a glock holder is acquired
go_dump Called to print content of object for debugfs file, or on
error to dump glock to the log.
-go_type The type of the glock, ``LM_TYPE_*``
go_callback Called if the DLM sends a callback to drop this lock
+go_unlocked Called when a glock is unlocked (dlm_unlock())
+go_type The type of the glock, ``LM_TYPE_*``
go_flags GLOF_ASPACE is set, if the glock has an address space
associated with it
-============= =============================================================
+============== =============================================================
The minimum hold time for each lock is the time after a remote lock
grant for which we ignore remote demote requests. This is in order to
@@ -82,26 +83,25 @@ to by multiple nodes. By delaying the demotion in response to a
remote callback, that gives the userspace program time to make
some progress before the pages are unmapped.
-There is a plan to try and remove the go_lock and go_unlock callbacks
-if possible, in order to try and speed up the fast path though the locking.
-Also, eventually we hope to make the glock "EX" mode locally shared
-such that any local locking will be done with the i_mutex as required
-rather than via the glock.
+Eventually, we hope to make the glock "EX" mode locally shared such that any
+local locking will be done with the i_mutex as required rather than via the
+glock.
Locking rules for glock operations:
-============= ====================== =============================
+============== ====================== =============================
Operation GLF_LOCK bit lock held gl_lockref.lock spinlock held
-============= ====================== =============================
-go_xmote_th Yes No
+============== ====================== =============================
+go_sync Yes No
go_xmote_bh Yes No
go_inval Yes No
go_demote_ok Sometimes Yes
-go_lock Yes No
-go_unlock Yes No
+go_instantiate No No
+go_held No No
go_dump Sometimes Yes
go_callback Sometimes (N/A) Yes
-============= ====================== =============================
+go_unlocked Yes No
+============== ====================== =============================
.. Note::
--
2.45.1
next prev parent reply other threads:[~2024-05-29 17:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-29 17:03 [PATCH 00/15] gfs2: Revise glock refcounting Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 01/15] gfs2: Remove unnecessary function prototype Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 02/15] gfs2: Remove useless return statement in run_queue Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 03/15] gfs2: Rename GLF_FREEING to GLF_UNLOCKED Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 04/15] gfs2: Rename GLF_REPLY_PENDING to GLF_HAVE_REPLY Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 05/15] gfs2: Rename GLF_FROZEN to GLF_HAVE_FROZEN_REPLY Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 06/15] gfs2: Rename handle_callback to request_demote Andreas Gruenbacher
2024-05-29 17:03 ` Andreas Gruenbacher [this message]
2024-05-29 17:03 ` [PATCH 08/15] gfs2: Remove outdated comment in glock_work_func Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 09/15] gfs2: Invert the GLF_INITIAL flag Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 10/15] gfs2: gfs2_glock_get cleanup Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 11/15] gfs2: Report when glocks cannot be freed for a long time Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 12/15] gfs2: Switch to a per-filesystem glock workqueue Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 13/15] gfs2: Revise glock reference counting model Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 14/15] Revert "GFS2: Don't add all glocks to the lru" Andreas Gruenbacher
2024-05-29 17:03 ` [PATCH 15/15] gfs2: Get rid of demote_ok checks Andreas Gruenbacher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240529170352.571141-8-agruenba@redhat.com \
--to=agruenba@redhat.com \
--cc=gfs2@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).