linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: linux-fsdevel@vger.kernel.org, akpm@osdl.org, zach.brown@oracle.com
Subject: [PATCH 0 of 8] O_DIRECT locking rework v5
Date: Thu, 21 Dec 2006 20:45:52 -0500	[thread overview]
Message-ID: <20061222014552.GA26388@think.oraclecorp.com> (raw)

[ resend, sorry for the messed up headers ]

I took a small detour on the O_DIRECT locking rework to look at
different alternatives for range locking in the pagecache.  After
benchmarking a few different types of trees, I didn't find anything that
would match radix for random lookup performance.

This patchset does ranges in the radix tree by inserting a placeholder
at the last slot in the range and forcing all lookups to search forward.
It means radix_tree_gang_lookup must be used instead of
radix_tree_lookup, but this is still faster for random searches than
anything else I tried.

A bit is set on the radix root node to indicate if range searching is
required.  So, when O_DIRECT isn't used or O_DIRECT is used for tiny
ios, no range lookups are done.

With O_DIRECT in use, only a single placeholder is inserted
to lock down the entire range for a given IO.  This should
stand up pretty well for those monster XFS workloads.

If the mapping has pages on it, I do one placeholder for every 64k
to limit the number of pages pinned down during the IO.  There's
lots of hand waving here, it may be best to get rid of this special
case.

Patch against Linus' git from today.  Testing has been light, I'm
mostly looking for comments on the range locking tricks.

-chris

             reply	other threads:[~2006-12-22  1:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-22  1:45 Chris Mason [this message]
2006-12-22  1:52 ` [PATCH 1 of 8] Introduce a place holder page for the pagecache Chris Mason
2006-12-22  1:55 ` [PATCH 2 of 8] Change O_DIRECT to use placeholders instead of i_mutex/i_alloc_sem locking Chris Mason
2006-12-22  1:57 ` [PATCH 3 of 8] DIO: don't fall back to buffered writes Chris Mason
2006-12-22  1:59 ` [PATCH 4 of 8] Add flags to control direct IO helpers Chris Mason
2006-12-22  2:00 ` [PATCH 5 of 8] Make ext3 safe for the new DIO locking rules Chris Mason
2006-12-22  2:02 ` [PATCH 6 of 8] Make reiserfs safe for " Chris Mason
2006-12-22  2:03 ` [PATCH 7 of 8] Adapt XFS to the new blockdev_direct_IO calls Chris Mason
2006-12-22  2:05 ` [PATCH 8 of 8] Avoid too many boundary buffers in DIO Chris Mason

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=20061222014552.GA26388@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=akpm@osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=zach.brown@oracle.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).