All of lore.kernel.org
 help / color / mirror / Atom feed
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
>



  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 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.