On Mar 10, 2016, at 6:23 PM, Al Viro wrote: > On Thu, Mar 10, 2016 at 09:22:21PM +0000, Drokin, Oleg wrote: >> The downside is that we do the allocation at all times even if the dentry is >> going to be promptly destroyed because we found a better alias. > > The cost of kmalloc() (or kmem_cache_alloc() - it might make sense > to introduce a specialized slab for those beasts) is trivial compared to the > cost of talking to server to find which inode you are going to deal with. It is, though it's not like we always need to talk to the server in those cases. Overhead is overhead no matter how small, and an extra check for the d_init d_op would happen for every filesystem, not just ceph and Lustre. Overhead also has this bad property of adding up. Yes, it's minuscule and CPUs are still getting somewhat faster. Is it worth it in the long run? May be, I do not have a strong opinion here since always doing ll_d_init after d_splice_alias solves the issue for us and does it in a way that does not affect anybody else. And as you correctly observed, most of users don't really care.-- 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
