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;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     trondmy@kernel.org
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH 4/5] NFS: Further optimisations for 'ls -l'
Date:   Wed, 29 Sep 2021 10:56:40 -0400
Message-ID: <C9ED123C-A092-4417-8597-AB6267379E2F@redhat.com>
In-Reply-To: <20210929134944.632844-4-trondmy@kernel.org>
References: <20210929134944.632844-1-trondmy@kernel.org>
 <20210929134944.632844-2-trondmy@kernel.org>
 <20210929134944.632844-3-trondmy@kernel.org>
 <20210929134944.632844-4-trondmy@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 29 Sep 2021, at 9:49, trondmy@kernel.org wrote:

> From: Trond Myklebust <trond.myklebust@hammerspace.com>
>
> If a user is doing 'ls -l', we have a heuristic in GETATTR that tells
> the readdir code to try to use READDIRPLUS in order to refresh the inode
> attributes. In certain cirumstances, we also try to invalidate the
> remaining directory entries in order to ensure this refresh.
>
> If there are multiple readers of the directory, we probably should avoid
> invalidating the page cache, since the heuristic breaks down in that
> situation anyway.

Hi Trond, I'm curious about the motivation for this work because we're often
managing expectations about performance between various workloads.  What
does the workload look like that prompted you to make this optimization?

I'm also interested because I have some work that improves readdir
performance for multiple readers on large directories, but is rotting
because things have been "good enough" for folks over here.

Ben