|| ||Chris Mason <firstname.lastname@example.org>|
|| ||email@example.com, firstname.lastname@example.org, email@example.com|
|| ||[PATCH 0 of 8] O_DIRECT locking rework v5|
|| ||Thu, 21 Dec 2006 20:45:52 -0500|
[ 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
Patch against Linus' git from today. Testing has been light, I'm
mostly looking for comments on the range locking tricks.
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html