linux-kernel - Re: [RFC/RFT PATCH 0/3] d

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20161207194624.GA8641@ZenIV.linux.org.uk>
Date:   Wed, 7 Dec 2016 19:46:24 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Miklos Szeredi <mszeredi@...hat.com>
Cc:     Trond Myklebust <trond.myklebust@...marydata.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC/RFT PATCH 0/3] d_time removal

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?
<checks on a fairly large local box>
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.