cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] dlm: Don't send callback to node making lock request when "try 1cb" fails
Date: Fri, 3 Sep 2010 11:13:24 -0400	[thread overview]
Message-ID: <20100903151324.GB28819@redhat.com> (raw)
In-Reply-To: <1283506816.2500.21.camel@localhost>

On Fri, Sep 03, 2010 at 10:40:16AM +0100, Steven Whitehouse wrote:
> 
> When converting a lock, an lkb is in the granted state and also being used
> to request a new state. In the case that the conversion was a "try 1cb"
> type which has failed, and if the new state was incompatible with the old
> state, a callback was being generated to the requesting node. This is
> incorrect as callbacks should only be sent to all the other nodes holding
> blocking locks. The requesting node should receive the normal (failed)
> response to its "try 1cb" conversion request only.
> 
> This was discovered while debugging a performance problem on GFS2, however
> this fix also speeds up GFS as well. In the GFS2 case the performance gain
> is over 10x for cases of write activity to an inode whose glock is cached
> on another, idle (wrt that glock) node.

Thanks, I added a comment and queued it up.
Dave


From 314dd2a05340fffbe217c5e40ec6c3bd1d07bf89 Mon Sep 17 00:00:00 2001
From: Steven Whitehouse <swhiteho@redhat.com>
Date: Fri, 3 Sep 2010 10:07:48 -0500
Subject: [PATCH] dlm: Don't send callback to node making lock request when "try 1cb" fails

When converting a lock, an lkb is in the granted state and also being used
to request a new state. In the case that the conversion was a "try 1cb"
type which has failed, and if the new state was incompatible with the old
state, a callback was being generated to the requesting node. This is
incorrect as callbacks should only be sent to all the other nodes holding
blocking locks. The requesting node should receive the normal (failed)
response to its "try 1cb" conversion request only.

This was discovered while debugging a performance problem on GFS2, however
this fix also speeds up GFS as well. In the GFS2 case the performance gain
is over 10x for cases of write activity to an inode whose glock is cached
on another, idle (wrt that glock) node.

(comment added, dct)

Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Tested-by: Abhijith Das <adas@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
---
 fs/dlm/lock.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index 031dbe3..64e5f3e 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -1846,6 +1846,9 @@ static void send_bast_queue(struct dlm_rsb *r, struct list_head *head,
 	struct dlm_lkb *gr;
 
 	list_for_each_entry(gr, head, lkb_statequeue) {
+		/* skip self when sending basts to convertqueue */
+		if (gr == lkb)
+			continue;
 		if (gr->lkb_bastfn && modes_require_bast(gr, lkb)) {
 			queue_bast(r, gr, lkb->lkb_rqmode);
 			gr->lkb_highbast = lkb->lkb_rqmode;
-- 
1.7.1.1



      reply	other threads:[~2010-09-03 15:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-03  9:40 [Cluster-devel] dlm: Don't send callback to node making lock request when "try 1cb" fails Steven Whitehouse
2010-09-03 15:13 ` David Teigland [this message]

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=20100903151324.GB28819@redhat.com \
    --to=teigland@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).