From: Steven Whitehouse <swhiteho@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [DLM PATCH] DLM: Don't wait for resource library lookups if NOLOOKUP is specified
Date: Wed, 01 Oct 2014 19:04:35 +0100 [thread overview]
Message-ID: <542C4233.1050206@redhat.com> (raw)
In-Reply-To: <1631293570.1178953.1412184101732.JavaMail.zimbra@redhat.com>
Hi,
On 01/10/14 18:21, Bob Peterson wrote:
> Hi,
>
> This patch adds a new lock flag, DLM_LKF_NOLOOKUP, which instructs DLM
> to refrain from sending lookup requests in cases where the lock library
> node is not the current node. This is similar to the DLM_LKF_NOQUEUE
> flag, except it fails locks that would require a lookup, with -EAGAIN.
>
> This is not just about saving a network operation. It allows callers
> like GFS2 to master locks for which they are the directory node. Each
> node can then "prefer" local locks, especially in the case of GFS2
> selecting resource groups for block allocations (implemented with a
> separate patch). This mastering of local locks distributes the locks
> between the nodes (at least until nodes enter or leave the cluster),
> which tends to make each node "keep to itself" when doing allocations.
> Thus, dlm communications are kept to a minimum, which results in
> significantly faster block allocations.
I think we need to do some more investigation here... how long do the
lookups take? If the issue is just to create a list of perferred rgrps
for each node, then there are various ways in which we might do that.
That is not to say that this isn't a good way to do it, but I think we
should try to understand the timings here first and make sure that we
are solving the right problem,
Steve.
> Regards,
>
> Bob Peterson
> Red Hat File Systems
>
> Signed-off-by: Bob Peterson <rpeterso@redhat.com>
> ---
> fs/dlm/lock.c | 16 ++++++++++++++--
> include/uapi/linux/dlmconstants.h | 7 +++++++
> 2 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
> index 83f3d55..f1e5b04 100644
> --- a/fs/dlm/lock.c
> +++ b/fs/dlm/lock.c
> @@ -222,6 +222,11 @@ static inline int can_be_queued(struct dlm_lkb *lkb)
> return !(lkb->lkb_exflags & DLM_LKF_NOQUEUE);
> }
>
> +static inline int can_be_looked_up(struct dlm_lkb *lkb)
> +{
> + return !(lkb->lkb_exflags & DLM_LKF_NOLOOKUP);
> +}
> +
> static inline int force_blocking_asts(struct dlm_lkb *lkb)
> {
> return (lkb->lkb_exflags & DLM_LKF_NOQUEUEBAST);
> @@ -2745,6 +2750,11 @@ static int set_master(struct dlm_rsb *r, struct dlm_lkb *lkb)
> return 0;
> }
>
> + if (!can_be_looked_up(lkb)) {
> + queue_cast(r, lkb, -EAGAIN);
> + return -EAGAIN;
> + }
> +
> wait_pending_remove(r);
>
> r->res_first_lkid = lkb->lkb_id;
> @@ -2828,7 +2838,8 @@ static int set_lock_args(int mode, struct dlm_lksb *lksb, uint32_t flags,
> if (flags & DLM_LKF_CONVDEADLK && !(flags & DLM_LKF_CONVERT))
> goto out;
>
> - if (flags & DLM_LKF_CONVDEADLK && flags & DLM_LKF_NOQUEUE)
> + if (flags & DLM_LKF_CONVDEADLK && (flags & (DLM_LKF_NOQUEUE |
> + DLM_LKF_NOLOOKUP)))
> goto out;
>
> if (flags & DLM_LKF_EXPEDITE && flags & DLM_LKF_CONVERT)
> @@ -2837,7 +2848,8 @@ static int set_lock_args(int mode, struct dlm_lksb *lksb, uint32_t flags,
> if (flags & DLM_LKF_EXPEDITE && flags & DLM_LKF_QUECVT)
> goto out;
>
> - if (flags & DLM_LKF_EXPEDITE && flags & DLM_LKF_NOQUEUE)
> + if (flags & DLM_LKF_EXPEDITE && (flags & (DLM_LKF_NOQUEUE |
> + DLM_LKF_NOLOOKUP)))
> goto out;
>
> if (flags & DLM_LKF_EXPEDITE && mode != DLM_LOCK_NL)
> diff --git a/include/uapi/linux/dlmconstants.h b/include/uapi/linux/dlmconstants.h
> index 47bf08d..4b9ba15 100644
> --- a/include/uapi/linux/dlmconstants.h
> +++ b/include/uapi/linux/dlmconstants.h
> @@ -131,6 +131,12 @@
> * Unlock the lock even if it is converting or waiting or has sublocks.
> * Only really for use by the userland device.c code.
> *
> + * DLM_LKF_NOLOOKUP
> + *
> + * Don't take any network time/bandwidth to do directory owner lookups.
> + * This is a lock for which we only care whether it's completely under
> + * local jurisdiction.
> + *
> */
>
> #define DLM_LKF_NOQUEUE 0x00000001
> @@ -152,6 +158,7 @@
> #define DLM_LKF_ALTCW 0x00010000
> #define DLM_LKF_FORCEUNLOCK 0x00020000
> #define DLM_LKF_TIMEOUT 0x00040000
> +#define DLM_LKF_NOLOOKUP 0x00080000
>
> /*
> * Some return codes that are not in errno.h
>
next prev parent reply other threads:[~2014-10-01 18:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <38741039.1176852.1412183985958.JavaMail.zimbra@redhat.com>
2014-10-01 17:21 ` [Cluster-devel] [DLM PATCH] DLM: Don't wait for resource library lookups if NOLOOKUP is specified Bob Peterson
2014-10-01 18:04 ` Steven Whitehouse [this message]
2014-10-03 17:24 ` Bob Peterson
2014-10-01 18:42 ` David Teigland
2014-10-03 17:28 ` Bob Peterson
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=542C4233.1050206@redhat.com \
--to=swhiteho@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 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 NNTP newsgroup(s).