On Wed, Oct 07, 2009 at 07:56:33AM -0700, Linus Torvalds wrote: > > > 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. Yes, sure. I'm just pointing out that it seems to do insane things (like reading /proc/mounts at regular intervals, although I don't see that in dbench source so I really hope it isn't libc being "smart"). I agree it is not a very good benchmark. > > 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. Hmm, the only issue is that we need a consistent load of the name pointer and the length, otherwise our memcmp might go crazy. We could solve this by another level of indirection so a rename only requires a pointer swap... But anyway at this approach I only use a single seqlock, because the negative case always falls out to the locked walk anyway (this again might be a bit conservative and something we could tighten up). > 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. Yeah, well at least the basics seem to be there. I agree it is not totally clean and will have some cases that need optimising, but it is something people can start looking at... -- 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
