Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: qmUCj455Zxau7Z9VFBULsSqg22FuoPz1iyWvjl7gKf7QvcN5MdgXJUjkIKC/Ls/MfJ/U6x2LaA
 xD+Rqz14VSBA==
Date:   Thu, 25 Jun 2020 19:20:55 +0000
From:   Frank van der Linden <fllinden@amazon.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     Trond Myklebust <trond.myklebust@hammerspace.com>,
        Chuck Lever <chuck.lever@oracle.com>,
        <linux-nfs@vger.kernel.org>
Subject: Re: nfsd filecache issues with v4
Message-ID: <20200625192054.GD29600@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
References: <20200608192122.GA19171@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
 <20200625171021.GC30655@fieldses.org>
 <20200625191205.GC29600@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200625191205.GC29600@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Thu, Jun 25, 2020 at 07:12:05PM +0000, Frank van der Linden wrote:
> Some ideas to alleviate the pain short of doing the above:
> 
> * Count v4 references to nfsd_file (filecache) structures. If there
>   is a v4 reference, don't have the file on the LRU, as it's pointless.
>   Do include it in the hash table so that v2/v3 users can find it. This
>   avoids the worst offender (nfsd_file_lru), but does still blow up
>   nfsd_file_hashtbl.
> 
> * Use rhashtable for the hashtables, as it can automatically grow/shrink
>   the number of buckets. I don't know if the rhashtable code could handle
>   the load, but it might be worth a shot.

In fact, don't even put an nfsd_file on the LRU until the first time its
references drop to 1, e.g. when it's no longer being used. Because it
will never be removed if the refs are > 1, in any case.

Let me come up with a patch for that, shouldn't be too hard.

- Frank