On Wed, 7 Oct 2009, Nick Piggin wrote: > > OK, I have a really basic patch that does store-free path walking > (except on the final element). Yay! > dbench is pretty nasty still because it seems to do a lot of stupid > things like reading from /proc/mounts all the time. You should largely forget about dbench, it can certainly be a useful benchmark, but at the same time it's certainly not a _meaningful_ one. There are better things to try. > The seqlock in the dentry is for getting consistent name,len pointer, > and also not giving a false positive if a rename has partially > overwritten the name string (false negatives are always fine in the > lock free lookup path but false positives are not). Possibly we > could make do with a per-sb seqlock for this (or just rename_lock). My plan was always to just use rename_lock, and only do it at the outer level (and do it for both lookup failures _and_ for the success case). Your approach is _way_ more conservative than I would have done, and also potentially much slower due to the seqlock-per-path-component thing. Remember: seqlocks are almost free on x86, but they can be reasonably expensive in other places. Hmm. Regardless, this very much does look like what I envisioned, apart from details like that. And maybe your per-dentry seqlock is the right choice. On x86, it certainly doesn't have the performance issues it could have in other places. I'd like Al to take a look, if he's around. Linus -- 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