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;
MIME-Version: 1.0
References: <165516173293.21248.14587048046993234326.stgit@noble.brown>
 <CAPt2mGNjWXad6e7nSUTu=0ez1qU1wBNegrntgHKm5hOeBs5gQA@mail.gmail.com>
 <165534094600.26404.4349155093299535793@noble.neil.brown.name>
 <CAPt2mGOw_PS-5KY-9WFzGOT=ax6PFhVYSTQG-dpXzV5MeGieYg@mail.gmail.com>
 <165544498126.26404.7712330810213588882@noble.neil.brown.name> <CAPt2mGNJYJ=pTmRRseJdeyvTDw9am6uNUaiZysDvU2bNcNJLQw@mail.gmail.com>
In-Reply-To: <CAPt2mGNJYJ=pTmRRseJdeyvTDw9am6uNUaiZysDvU2bNcNJLQw@mail.gmail.com>
From:   Daire Byrne <daire@dneg.com>
Date:   Mon, 20 Jun 2022 11:18:54 +0100
Message-ID: <CAPt2mGOmcmJsDBZ1BN0G==u=OSMd91bicFk+-05g44CGbi1PLQ@mail.gmail.com>
Subject: Re: [PATCH RFC 00/12] Allow concurrent directory updates.
To:     NeilBrown <neilb@suse.de>
Cc:     Anna Schumaker <schumaker.anna@gmail.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        Chuck Lever <chuck.lever@oracle.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        linux-fsdevel@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 17 Jun 2022 at 16:27, Daire Byrne <daire@dneg.com> wrote:
> This patch does the job for me - no more stack traces and things have
> been stable all day. I'm going to run some production loads over the
> weekend and then I'll do some more artificial scale testing next week.
>
> Thanks again for this work! Improving the parallelism anywhere we can
> for single clients and then nfsd is great for reexport servers
> (especially once you add some "cloud" latency).
>
> Cheers,
>
> Daire

The patch ran without incident with our production re-export workloads
over the weekend (which also helps audit v5.19-rc2).

I ran a couple more synthetic tests and got up to 100 clients of a
re-export server and ~113 creates/s aggregate to a single directory
with 200ms latency to the originating server. This compares well with
the ~121 create/s when using 100 threads on a single patched client
direct to the remote NFS server.

In other words, the NFSD portion of this patch is delivering almost
the same performance as the underlying VFS NFS client performance when
re-exporting that path to hundreds of clients.

Again, without this patch we can only sustain just under 3 create/s in
both cases (VFS/NFSD) with 200ms latency.

This is a great improvement for our batch workloads with varying
amounts of latency >10ms (cloud networking).

Tested-by: Daire Byrne <daire@dneg.com>

Daire