From: Daire Byrne <daire@dneg.com>
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>
Subject: Re: [PATCH RFC 00/12] Allow concurrent directory updates.
Date: Mon, 20 Jun 2022 11:18:54 +0100 [thread overview]
Message-ID: <CAPt2mGOmcmJsDBZ1BN0G==u=OSMd91bicFk+-05g44CGbi1PLQ@mail.gmail.com> (raw)
In-Reply-To: <CAPt2mGNJYJ=pTmRRseJdeyvTDw9am6uNUaiZysDvU2bNcNJLQw@mail.gmail.com>
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
next prev parent reply other threads:[~2022-06-20 10:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 23:18 [PATCH RFC 00/12] Allow concurrent directory updates NeilBrown
2022-06-13 23:18 ` [PATCH 04/12] VFS: move dput() and mnt_drop_write() into done_path_update() NeilBrown
2022-06-13 23:18 ` [PATCH 03/12] VFS: move want_write checks into lookup_hash_update() NeilBrown
2022-06-13 23:18 ` [PATCH 02/12] VFS: move EEXIST and ENOENT tests " NeilBrown
2022-06-13 23:18 ` [PATCH 01/12] VFS: support parallel updates in the one directory NeilBrown
2022-06-13 23:18 ` [PATCH 05/12] VFS: export done_path_update() NeilBrown
2022-06-13 23:18 ` [PATCH 08/12] nfsd: allow parallel creates from nfsd NeilBrown
2022-06-24 14:43 ` Chuck Lever III
2022-06-28 22:35 ` Chuck Lever III
2022-06-28 23:09 ` NeilBrown
2022-07-04 17:17 ` Chuck Lever III
2022-06-13 23:18 ` [PATCH 07/12] NFS: support parallel updates in the one directory NeilBrown
2022-06-13 23:18 ` [PATCH 11/12] nfsd: use (un)lock_inode instead of fh_(un)lock NeilBrown
2022-06-24 14:43 ` Chuck Lever III
2022-06-13 23:18 ` [PATCH 06/12] VFS: support concurrent renames NeilBrown
2022-06-14 4:35 ` kernel test robot
2022-06-14 12:37 ` kernel test robot
2022-06-14 13:28 ` kernel test robot
2022-06-26 13:07 ` [VFS] 46a2afd9f6: ltp.rename10.fail kernel test robot
2022-06-26 13:07 ` kernel test robot
2022-06-26 13:07 ` [LTP] " kernel test robot
2022-06-13 23:18 ` [PATCH 12/12] nfsd: discard fh_locked flag and fh_lock/fh_unlock NeilBrown
2022-06-24 14:43 ` Chuck Lever III
2022-06-13 23:18 ` [PATCH 10/12] nfsd: reduce locking in nfsd_lookup() NeilBrown
2022-06-24 14:43 ` Chuck Lever III
2022-06-13 23:18 ` [PATCH 09/12] nfsd: support concurrent renames NeilBrown
2022-06-24 14:43 ` Chuck Lever III
2022-06-15 13:46 ` [PATCH RFC 00/12] Allow concurrent directory updates Daire Byrne
2022-06-16 0:55 ` NeilBrown
2022-06-16 10:48 ` Daire Byrne
2022-06-17 5:49 ` NeilBrown
2022-06-17 15:27 ` Daire Byrne
2022-06-20 10:18 ` Daire Byrne [this message]
2022-06-16 13:49 ` Anna Schumaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPt2mGOmcmJsDBZ1BN0G==u=OSMd91bicFk+-05g44CGbi1PLQ@mail.gmail.com' \
--to=daire@dneg.com \
--cc=chuck.lever@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=schumaker.anna@gmail.com \
--cc=trond.myklebust@hammerspace.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.