linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>
Subject: [PATCH 5/6] btrfs: simplify waiting loop in btrfs_tree_lock
Date: Wed, 23 Jan 2019 18:38:16 +0100	[thread overview]
Message-ID: <cc392a65b45fc90672c8e1ebf5f81cc96254a964.1548264220.git.dsterba@suse.com> (raw)
In-Reply-To: <cover.1548264220.git.dsterba@suse.com>

Currently, the number of readers and writers is checked and in case
there are any, wait and redo the locks. There's some duplication
before the branches go back to again label, eg. calling wait_event on
blocking_readers twice.

The sequence is transformed

loop:
* wait for readers
* wait for writers
* write_lock
* check readers, unlock and wait for readers, loop
* check writers, unlock and wait for writers, loop

The new sequence is not exactly the same due to the simplification, for
readers it's slightly faster. For the writers, original code does

* wait for writers
* (loop) wait for readers
*        wait for writers -- again

while the new goes directly to the reader check. This should behave the
same on a contended lock with multiple writers and readers, but can
reduce number of times we're waiting on something.

Signed-off-by: David Sterba <dsterba@suse.com>
---
 fs/btrfs/locking.c | 11 ++---------
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/fs/btrfs/locking.c b/fs/btrfs/locking.c
index 7f89ca6f1fbc..82b84e4daad1 100644
--- a/fs/btrfs/locking.c
+++ b/fs/btrfs/locking.c
@@ -237,16 +237,9 @@ void btrfs_tree_lock(struct extent_buffer *eb)
 	wait_event(eb->read_lock_wq, atomic_read(&eb->blocking_readers) == 0);
 	wait_event(eb->write_lock_wq, atomic_read(&eb->blocking_writers) == 0);
 	write_lock(&eb->lock);
-	if (atomic_read(&eb->blocking_readers)) {
+	if (atomic_read(&eb->blocking_readers) ||
+	    atomic_read(&eb->blocking_writers)) {
 		write_unlock(&eb->lock);
-		wait_event(eb->read_lock_wq,
-			   atomic_read(&eb->blocking_readers) == 0);
-		goto again;
-	}
-	if (atomic_read(&eb->blocking_writers)) {
-		write_unlock(&eb->lock);
-		wait_event(eb->write_lock_wq,
-			   atomic_read(&eb->blocking_writers) == 0);
 		goto again;
 	}
 	WARN_ON(atomic_read(&eb->spinning_writers));
-- 
2.20.1


  parent reply	other threads:[~2019-01-23 17:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 17:37 [PATCH 0/6] Extent buffer locking cleanups, part 1 David Sterba
2019-01-23 17:38 ` [PATCH 1/6] btrfs: split btrfs_set_lock_blocking_rw to read and write helpers David Sterba
2019-01-24  9:05   ` Johannes Thumshirn
2019-01-23 17:38 ` [PATCH 2/6] btrfs: split btrfs_clear_lock_blocking_rw " David Sterba
2019-01-24  9:06   ` Johannes Thumshirn
2019-01-23 17:38 ` [PATCH 3/6] btrfs: replace btrfs_set_lock_blocking_rw with appropriate helpers David Sterba
2019-01-24  9:06   ` Johannes Thumshirn
2019-01-23 17:38 ` [PATCH 4/6] btrfs: open code now trivial btrfs_set_lock_blocking David Sterba
2019-01-24  9:07   ` Johannes Thumshirn
2019-01-23 17:38 ` David Sterba [this message]
2019-01-24  9:08   ` [PATCH 5/6] btrfs: simplify waiting loop in btrfs_tree_lock Johannes Thumshirn
2019-01-23 17:38 ` [PATCH 6/6] btrfs: merge btrfs_set_lock_blocking_rw with it's caller David Sterba
2019-01-24  9:08   ` Johannes Thumshirn

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=cc392a65b45fc90672c8e1ebf5f81cc96254a964.1548264220.git.dsterba@suse.com \
    --to=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).