dcache_rcu [performance results]

I should add that this is a general trend we see in all workloads that do a lot of open/closes and so much so that performance is very sensitive to how close to / your application's working directory is. You would get much better system time if you compile a kernel in /linux as compared to say /home/fs01/users/akpm/kernel/linux ;-)

Quoted 6 lines · Dipankar Sarma

I should add that this is a general trend we see in all workloads that do a lot of open/closes and so much so that performance is very sensitive to how close to / your application's working directory is. You would get much better system time if you compile a kernel in /linux as compared to say /home/fs01/users/akpm/kernel/linux ;-)

That's interesting. Perhaps it would make sense to have a fast path that just does a string match of the to be looked up path to a cached copy of cwd and if it matches works as if cwd was the root. Would need to be careful with chroot where cwd could be outside the root and clear the cached copy in this case. Then you could avoid all the locking overhead for directories above your cwd if you stay in there.

Well, on second thoughts I can't see why the path length for pwd would make difference for kernel compilation - it uses relative path and for path lookup, if the first character is not '/', then lookup is done relative to current->fs->pwd. I will do some more benchmarking on and verify.

Kernel compilation actually uses absolute pathnames e.g. for dependency checking.

Quoted 2 lines

Kernel compilation actually uses absolute pathnames e.g. for dependency checking.

This used to be true, but it shouldn't be true any more. TOPDIR should be gone, and everything should be relative paths (and all "make" invocations should just be done from the top kernel directory).

But yes, it certainly _used_ to be true (and hey, maybe I've missed some reason for why it isn't still true).