From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 7 Dec 2016 19:46:24 +0000 From: Al Viro To: Miklos Szeredi Cc: Trond Myklebust , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC/RFT PATCH 0/3] d_time removal Message-ID: <20161207194624.GA8641@ZenIV.linux.org.uk> References: <1478515920-20458-1-git-send-email-mszeredi@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1478515920-20458-1-git-send-email-mszeredi@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: On Mon, Nov 07, 2016 at 11:51:57AM +0100, Miklos Szeredi wrote: > Only two filesystems remaining: nfs and ncpfs. Both use d_fsdata as well > as d_time which means we have to allocate a separate structure (RCU freed > in case of NFS). > > I still haven't tested these; hoping someone will do it for me. I would suggest profiling the NFS part - you are introducing a separate allocation for every dentry there, which could get unpleasant for something like dcache seeding in readdir. Another interesting part is the extra cachelines accessed in ->d_revalidate(). In principle, getting rid of ->d_time is nice, but the benefits are not all that impressive - slightly longer embedded names, but how many files have names between 32 and 40 characters long? 33 0.201368% 34 0.183738% 35 0.154355% 36 0.133560% 37 0.117422% 38 0.963897% 39 0.083879% 40 0.156796% IOW, here it's just a bit under 2% - not a lot. Getting rid of fs-specific fields in struct dentry per se... Fine, but that'd better not come at the cost of appreciable NFS overhead.