Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Benjamin Coddington <bcodding@redhat.com>
To:     Trond Myklebust <trondmy@hammerspace.com>,
        Anna Schumaker <anna@kernel.org>,
        "Kornievskaia, Olga" <Olga.Kornievskaia@netapp.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFS: Trigger the "ls -l" readdir heuristic sooner
Date:   Fri, 21 Oct 2022 08:43:45 -0400
Message-ID: <2B40F919-4E12-4891-B732-59650B507AA9@redhat.com>
In-Reply-To: <20220920170021.1391560-1-bcodding@redhat.com>
References: <20220920170021.1391560-1-bcodding@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 20 Sep 2022, at 13:00, Benjamin Coddington wrote:

> Since commit 1a34c8c9a49e ("NFS: Support larger readdir buffers") has
> updated dtsize, and with recent improvements to the READDIRPLUS helper
> heuristic, the heuristic may not trigger until many dentries are emitte=
d
> to userspace.   This will cause many thousands of GETATTR calls for "ls=

> -l" when the directory's pagecache has already been populated.  This
> manifests as poor performance for long directory listings after an
> initially fast "ls -l".
>
> Fix this by emitting only 17 entries for any first pass through the NFS=

> directory's ->iterate_shared(), which allows userpace to prime the
> counters for the heuristic.
>
> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
> ---

Hello Trond and Anna, please consider this patch.  We have folks that are=

sad and confused that "ls -l" becomes much slower after running it once.

Olga also tested this fix and reported performance gains here:
https://lore.kernel.org/linux-nfs/CAN-5tyFsJy-D9cEfk8zCH8-0KErWteVW8Zb7BM=
qjL7=3D=3D2qtT_A@mail.gmail.com/

Olga, would you be willing to contribute your "Tested-by" for this patch?=


Any comments from anyone would also be welcome.

Ben