On Thu, Oct 08, 2009 at 12:22:35AM +0200, Andi Kleen wrote: > On Wed, Oct 07, 2009 at 02:57:20PM -0700, Linus Torvalds wrote: > > There's no question that prefetching cannot help, but it helps only if > > it's about fetching data that you would need anyway early. In contrast, if > > the option is "don't touch the other cacheline at all", prefetching is > > _always_ a loss. No ifs, buts and maybes about it. > > My point (probably not very well written expressed) > was that in a typical VFS operation there are hundreds > of cache lines touched for various things (code, global, various > objects, random stuff) and one more or less in the final dentry > is not that big a difference in the global picture. > (ok I realize final in this case means the elements in the path) Yes I do know what you were getting at... Although I would say dcache is still fairly significant. It's 3 cachelines for every single path element we look up. Now I suspect it has been a while since someone closely looked at the cache layout with an eye to the lookup code. Actually no, it does look relatively sane (I guess it doesn't change that much), except it might actualy be a nice idea to move d_iname up to about above d_lru, so we could actually do path lookup in 2 cachelines per entry (or even 1 if we they have very short names). I will do a bit of profiling on the lookup code and see... -- 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
