>From chris.mason@xxxxxxxxxx Thu Dec 21 15:34:57 2006 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [PATCH 0 of 8] O_DIRECT locking rework v3 Message-Id: <patchbomb.1166733296@xxxxxxxxxxxxxxxxxxx> Date: Thu, 21 Dec 2006 15:34:56 -0400 From: Chris Mason <chris.mason@xxxxxxxxxx> To: linux-fsdevel@xxxxxxxxxxxxxxx, akpm@xxxxxxxx, zach.brown@xxxxxxxxxx [ resend, sorry for the last set of 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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
