From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH 3/6] GFS2: Refactor function fast_to_acquire
Date: Mon, 15 Jan 2018 11:24:33 -0500 (EST) [thread overview]
Message-ID: <534618369.7063973.1516033473381.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <59783a9b-93e1-09c5-9ae1-0d3f62cb35fe@redhat.com>
Hi,
Looking at this again: Today's fast_to_acquire function checks:
(1) if the rgrp glock is locked, has no holders and is not being
demoted, it considers it fast to acquire.
(2) If the rgrp glock is "preferred," it STILL considers it fast to
acquire.
So with today's code, even if a "preferred" glock was being demoted,
for example, it would still consider it fast to acquire.
So the replacement patch's logic is not that different from what
we have today; it's just that the "preferred rgrps" case is now
checked first.
So is today's logic wrong then too?
Bob
----- Original Message -----
| Hi,
|
|
| On 10/01/18 20:42, Bob Peterson wrote:
| > Function fast_to_acquire determines if a rgrp ought to be fast to
| > acquire, but the logic was cryptic. This patch makes the logic more
| > straightforward:
| >
| > 1. If the rgrp is one of our "preferred" rgrps, consider it fast
| > to acquire. This is how each node tries to confine its allocations
| > to a set of rgrps unique from the other nodes, to reduce contention.
| > 2. If the rgrp glock is unlocked, consider it slow, because it will
| > take some time to lock it, either for the DLM or for the glock
| > state machine.
| > 3. If there are glock holders, consider it slow because we'd have to
| > wait for another process to dequeue before we get our turn.
| > 4. If the glock is being demoted, consider it slow.
| >
| > Signed-off-by: Bob Peterson <rpeterso@redhat.com>
| This appears to mean that for preferred rgrps we will no longer take
| into account any of the other conditions. I'm not sure that is right,
| since we want to avoid rgrps that are in use by other nodes, or are
| being demoted, even if they are preferred. The location of the DLM lock
| master is not really that critical, the slow thing is the I/O that is
| done under the glocks,
|
| Steve.
|
| > ---
| > fs/gfs2/rgrp.c | 30 +++++++++++++++++++++---------
| > 1 file changed, 21 insertions(+), 9 deletions(-)
| >
| > diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c
| > index 960fbc2d39d7..fa72e3e6ce4e 100644
| > --- a/fs/gfs2/rgrp.c
| > +++ b/fs/gfs2/rgrp.c
| > @@ -1938,20 +1938,32 @@ static bool gfs2_select_rgrp(struct gfs2_rgrpd
| > **pos, const struct gfs2_rgrpd *b
| > /**
| > * fast_to_acquire - determine if a resource group will be fast to
| > acquire
| > *
| > - * If this is one of our preferred rgrps, it should be quicker to acquire,
| > - * because we tried to set ourselves up as dlm lock master.
| > + * 1. If this is one of our preferred rgrps, it should be quicker to
| > acquire,
| > + * because we tried to set ourselves up as dlm lock master.
| > + * 2. If the glock is unlocked, consider it slow because it will take time
| > for
| > + * the dlm and the glock state machine to transition it to a locked
| > state.
| > + * 3. If there are glock holder records queued to the glock, consider it
| > slow
| > + * because this process will need to be queued up behind another
| > process:
| > + * Our request can't be enqueued until the other is dequeued.
| > + * 4. If the rgrp glock is being demoted, consider it slow because the
| > glock
| > + * will need to be demoted, possibly used on another node, the
| > promoted,
| > + * all of which will take time.
| > + *
| > */
| > -static inline int fast_to_acquire(struct gfs2_rgrpd *rgd)
| > +static inline bool fast_to_acquire(struct gfs2_rgrpd *rgd)
| > {
| > struct gfs2_glock *gl = rgd->rd_gl;
| >
| > - if (gl->gl_state != LM_ST_UNLOCKED && list_empty(&gl->gl_holders) &&
| > - !test_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags) &&
| > - !test_bit(GLF_DEMOTE, &gl->gl_flags))
| > - return 1;
| > if (rgd->rd_flags & GFS2_RDF_PREFERRED)
| > - return 1;
| > - return 0;
| > + return true;
| > + if (gl->gl_state == LM_ST_UNLOCKED)
| > + return false;
| > + if (!list_empty(&gl->gl_holders))
| > + return false;
| > + if (test_bit(GLF_DEMOTE_IN_PROGRESS, &gl->gl_flags) ||
| > + test_bit(GLF_DEMOTE, &gl->gl_flags))
| > + return false;
| > + return true;
| > }
| >
| > /**
|
|
next prev parent reply other threads:[~2018-01-15 16:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 20:42 [Cluster-devel] [GFS2 PATCH 0/6] [resend] GFS2: Rework rgrp glock congestion functions for intra-node Bob Peterson
2018-01-10 20:42 ` [Cluster-devel] [GFS2 PATCH 1/6] GFS2: Simplify gfs2_rgrp_used_recently Bob Peterson
2018-01-10 20:42 ` [Cluster-devel] [GFS2 PATCH 2/6] GFS2: Check gfs2_rgrp_used_recently inside gfs2_rgrp_congested Bob Peterson
2018-01-12 10:45 ` Steven Whitehouse
2018-01-15 15:48 ` Bob Peterson
2018-01-10 20:42 ` [Cluster-devel] [GFS2 PATCH 3/6] GFS2: Refactor function fast_to_acquire Bob Peterson
2018-01-12 10:51 ` Steven Whitehouse
2018-01-15 16:00 ` Bob Peterson
2018-01-15 16:24 ` Bob Peterson [this message]
2018-01-10 20:42 ` [Cluster-devel] [GFS2 PATCH 4/6] GFS2: Simplify by checking fast_to_acquire in gfs2_rgrp_congested Bob Peterson
2018-01-12 10:55 ` Steven Whitehouse
2018-01-10 20:42 ` [Cluster-devel] [GFS2 PATCH 5/6] GFS2: Split gfs2_rgrp_congested into dlm and non-dlm cases Bob Peterson
2018-01-10 20:42 ` [Cluster-devel] [GFS2 PATCH 6/6] GFS2: Add checks for intra-node congestion Bob Peterson
2018-01-12 11:11 ` Steven Whitehouse
2018-01-11 15:52 ` [Cluster-devel] [GFS2 PATCH 0/6] [resend] GFS2: Rework rgrp glock congestion functions for intra-node Abhijith Das
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=534618369.7063973.1516033473381.JavaMail.zimbra@redhat.com \
--to=rpeterso@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.