From: Liu Bo <liubo2009@cn.fujitsu.com>
To: <linux-btrfs@vger.kernel.org>
Subject: [PATCH 0/6 v3][RFC] rwlock for extent state
Date: Wed, 25 Jul 2012 13:58:36 +0800 [thread overview]
Message-ID: <1343195922-31405-1-git-send-email-liubo2009@cn.fujitsu.com> (raw)
This patchset is against one of project ideas, RBtree lock contention:
"Btrfs uses a number of rbtrees to index in-memory data structures.
Some of these are dominated by reads, and the lock contention from searching
them is showing up in profiles. We need to look into an RCU and sequence
counter combination to allow lockless reads."
So the real goal is to use RCU, but we take it as a long term one, instead
we use rwlock until we find a mature rcu structure for lockless read.
So what we need to do is to make the code RCU friendly, and the idea mainly
comes from Chris Mason:
Quoted:
"I think the extent_state code can be much more RCU friendly if we separate
the operations on the tree from operations on the individual state.
In general, we can gain a lot of performance if we are able to reduce
the write locks taken at endio time. Especially for reads, these are
critical."
In this patch set, at least we now make the endio of readpage a write-lock free
path, so our multi-thread read will benefit from this.
ANY TEST and COMMENTs are welcome!
v2->v3: - fix a deadlock bug on state's lock
- drop the individual radix tree for checksum to get rid of another lock.
v1->v2: drop changes on invalidatepage() and rebase to the latest btrfs
upstream.
Liu Bo (6):
Btrfs: merge adjacent states as much as possible
Btrfs: add helper function to test if we can merge state
Btrfs: break clear_state_bit into two parts
Btrfs: apply rwlock for extent state
Btrfs: batch merge state in readpage endio
Btrfs: async helper for state merge
fs/btrfs/ctree.h | 1 +
fs/btrfs/disk-io.c | 6 +
fs/btrfs/extent_io.c | 476 +++++++++++++++++++++++++++++++++++++++++++-------
fs/btrfs/extent_io.h | 4 +-
fs/btrfs/super.c | 1 +
5 files changed, 423 insertions(+), 65 deletions(-)
next reply other threads:[~2012-07-25 5:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 5:58 Liu Bo [this message]
2012-07-25 5:58 ` [PATCH 1/6 v3][RFC] Btrfs: merge adjacent states as much as possible Liu Bo
2012-07-25 5:58 ` [PATCH 2/6 v3][RFC] Btrfs: add helper function to test if we can merge state Liu Bo
2012-07-25 5:58 ` [PATCH 3/6 v3][RFC] Btrfs: break clear_state_bit into two parts Liu Bo
2012-07-25 5:58 ` [PATCH 4/6 v3][RFC] Btrfs: apply rwlock for extent state Liu Bo
2012-07-25 5:58 ` [PATCH 5/6 v3][RFC] Btrfs: batch merge state in readpage endio Liu Bo
2012-07-25 5:58 ` [PATCH 6/6 v3][RFC] Btrfs: async helper for state merge Liu Bo
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=1343195922-31405-1-git-send-email-liubo2009@cn.fujitsu.com \
--to=liubo2009@cn.fujitsu.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).