From: David Sterba <dsterba@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>
Subject: [PATCH 00/11] Cleanup dev-replace locking
Date: Fri, 7 Sep 2018 16:54:59 +0200 [thread overview]
Message-ID: <cover.1536331604.git.dsterba@suse.com> (raw)
The series peels off the custom locking that's used for dev-replace and
uses read-write semaphore in the end.
I've mainly focused on correctness and haven't measured the performance
effects. There should be none as the blocking and waiting was merely
open coding what the rw semaphore does, but without the fairness. The
overall number of locks taken is low, there's a lots of IO in between so
even if new scheme is slower, I don't expect any dramatic change.
git://github.com/kdave/btrfs-devel.git dev/dev-replace-locking
David Sterba (11):
btrfs: remove btrfs_dev_replace::read_locks
btrfs: open code btrfs_dev_replace_clear_lock_blocking
btrfs: open code btrfs_dev_replace_stats_inc
btrfs: open code btrfs_after_dev_replace_commit
btrfs: dev-replace: avoid useless lock on error handling path
btrfs: dev-replace: move replace members out of fs_info
btrfs: dev-replace: remove pointless assert in write unlock
btrfs: reada: reorder dev-replace locks before radix tree preload
btrfs: dev-replace: swich locking to rw semaphore
btrfs: dev-replace: remove custom read/write blocking scheme
btrfs: dev-replace: open code trivial locking helpers
fs/btrfs/ctree.h | 11 ++--
fs/btrfs/dev-replace.c | 136 ++++++++++++-----------------------------
fs/btrfs/dev-replace.h | 13 ----
fs/btrfs/disk-io.c | 14 ++---
fs/btrfs/reada.c | 16 ++---
fs/btrfs/scrub.c | 26 ++++----
fs/btrfs/transaction.c | 5 +-
fs/btrfs/volumes.c | 23 ++++---
8 files changed, 87 insertions(+), 157 deletions(-)
--
2.18.0
next reply other threads:[~2018-09-07 19:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-07 14:54 David Sterba [this message]
2018-09-07 14:55 ` [PATCH 01/11] btrfs: remove btrfs_dev_replace::read_locks David Sterba
2018-09-07 14:55 ` [PATCH 02/11] btrfs: open code btrfs_dev_replace_clear_lock_blocking David Sterba
2018-09-07 14:55 ` [PATCH 03/11] btrfs: open code btrfs_dev_replace_stats_inc David Sterba
2018-09-07 21:02 ` Omar Sandoval
2018-09-07 14:55 ` [PATCH 04/11] btrfs: open code btrfs_after_dev_replace_commit David Sterba
2018-09-07 21:03 ` Omar Sandoval
2018-09-07 14:55 ` [PATCH 05/11] btrfs: dev-replace: avoid useless lock on error handling path David Sterba
2018-09-07 21:06 ` Omar Sandoval
2018-09-14 16:53 ` David Sterba
2018-09-07 14:55 ` [PATCH 06/11] btrfs: dev-replace: move replace members out of fs_info David Sterba
2018-09-07 21:09 ` Omar Sandoval
2018-09-07 14:55 ` [PATCH 07/11] btrfs: dev-replace: remove pointless assert in write unlock David Sterba
2018-09-07 14:55 ` [PATCH 08/11] btrfs: reada: reorder dev-replace locks before radix tree preload David Sterba
2018-09-07 14:55 ` [PATCH 09/11] btrfs: dev-replace: swich locking to rw semaphore David Sterba
2018-09-07 14:55 ` [PATCH 10/11] btrfs: dev-replace: remove custom read/write blocking scheme David Sterba
2018-09-07 14:55 ` [PATCH 11/11] btrfs: dev-replace: open code trivial locking helpers David Sterba
2018-09-27 11:06 ` [PATCH 00/11] Cleanup dev-replace locking David Sterba
2018-10-04 1:06 ` Anand Jain
2018-10-04 10:13 ` David Sterba
2018-10-05 8:58 ` Anand Jain
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=cover.1536331604.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).