Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Tom Haynes <loghyr@gmail.com>,
	Trond Myklebust <trondmy@hammerspace.com>,
	 Mike Snitzer <snitzer@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>,
	Anna Schumaker <anna@kernel.org>,
	 linux-nfs@vger.kernel.org
Subject: OPEN_XOR_DELEGATION performance problems
Date: Tue, 19 Nov 2024 06:45:53 -0500	[thread overview]
Message-ID: <d5b8d3d6c7592808ad1332ae8c7c2f2cc9635550.camel@kernel.org> (raw)

We attempted to implement the "delstid" draft for v6.13, but have had
to drop the patches for it. After merge, we got a couple of reports of
a performance issue due to the OPEN_XOR_DELEGATION patch:

    https://lore.kernel.org/linux-nfs/202409161645.d44bced5-oliver.sang@intel.com/

Once we enable OPEN_XOR_DELEGATION support, the fsmark "App Overhead"
statistic spikes significantly. The kernel patch for this is very
simple, and doesn't seem likely to cause a performance issue on its
own. My theory is that this test is one that causes the client to
return the delegation, and since it doesn't have an open stateid, it
has to reestablish one during the test run, and that causes the app
overhead stat to spike.

Trond, Tom, Mike -- I know that the HS Anvil has support for
OPEN_XOR_DELEGATION. If you run the fsmark test against it with that
support both enabled and disabled (either on the client or server
side), do you see a similar spike in "App Overhead"?

If so, then I suspect we need to consider limiting the use of that flag
in some cases. I have no idea what heuristic we'd use to decide this
though.
-- 
Jeff Layton <jlayton@kernel.org>

             reply	other threads:[~2024-11-19 11:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19 11:45 Jeff Layton [this message]
2024-11-19 15:09 ` OPEN_XOR_DELEGATION performance problems Trond Myklebust
2024-11-19 16:23   ` Chuck Lever III
2024-11-19 16:37     ` Jeff Layton
2024-11-20  7:39     ` Cedric Blancher
2024-11-20 12:11       ` Mkrtchyan, Tigran

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=d5b8d3d6c7592808ad1332ae8c7c2f2cc9635550.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=anna@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=loghyr@gmail.com \
    --cc=snitzer@kernel.org \
    --cc=trondmy@hammerspace.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox