All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>, NeilBrown <neil@brown.name>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 0/4] NFSD: CB_RECALL_ANY fixes and a meaningful keep count
Date: Wed, 12 Aug 2026 13:36:24 -0400	[thread overview]
Message-ID: <a2cfbd0dc381f3ebb40f5702be83c0ae4fd693c7.camel@kernel.org> (raw)
In-Reply-To: <20260812-recall-any-keep-count-v2-0-a82f4ca23812@kernel.org>

On Wed, 2026-08-12 at 10:59 -0400, Chuck Lever wrote:
> NFSD sends every CB_RECALL_ANY with craa_objects_to_keep set to
> zero, as RFC 8881 Section 20.6.3 does not mandate any particular
> way for a client to choose which delegations to choose, if any.
> 
> However, a zero value can result in some clients giving back more
> delegations than is necessary to relieve temporary memory pressure
> on the server, which needlessly impacts performance.
> 
> NFSD intends the callback as a signal to return unused delegations.
> Only the Linux client has been tested against it, and that client
> ignores craa_objects_to_keep and returns only one unused delegation
> of the named types, so the fixed zero never produced visible
> misbehavior during our testing.
> 
> So, change NFSD so that each CB_RECALL_ANY asks a client to give up
> one delegation. Both reaper callers (the shrinker to relieve memory
> pressure, and the laundromat to cap the total number of delegations
> the server tracks) re-arm while their condition lasts.
> 
> NFSD sets no recall target and remembers nothing across CB_RECALL_ANY
> callbacks. RFC 8881 Section 20.6.4 prescribes the use of CB_RECALL
> to target specific delegations if a client fails to return any. NFSD
> does not take that step yet. CB_RECALL_ANY is asynchronous and
> reports no completion, so NFSD treats it as advisory.
> 
> ---
> Changes in v2:
> - Drop the gate that skipped clients holding a single delegation.
> - Cover letter rewritten to give performance rationale.
> - Link to v1: https://patch.msgid.link/20260811-recall-any-keep-count-v1-0-de9ca00493b7@kernel.org
> 
> ---
> Chuck Lever (4):
>       NFSD: Do not send CB_RECALL_ANY to NFSv4.0 clients
>       NFSD: Count the delegations held by each client
>       NFSD: Name directory delegations in the CB_RECALL_ANY type mask
>       NFSD: Send a meaningful CB_RECALL_ANY keep count
> 
>  fs/nfsd/nfs4state.c | 27 +++++++++++++++++++++++----
>  fs/nfsd/state.h     |  2 ++
>  2 files changed, 25 insertions(+), 4 deletions(-)
> ---
> base-commit: 1d479c6b53f684b27da84ec352b7efb97f7f115f
> change-id: 20260810-recall-any-keep-count-f50c2ae1b792
> 
> Best regards,
> --  
> Chuck Lever <cel@kernel.org>

Looks reasonable. Given that the Linux client ignores
craa_objects_to_keep and just sends back a single delegation, this
should keep things working the same even when it's brought into
compliance.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

      parent reply	other threads:[~2026-08-12 17:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 14:59 [PATCH v2 0/4] NFSD: CB_RECALL_ANY fixes and a meaningful keep count Chuck Lever
2026-08-12 14:59 ` [PATCH v2 1/4] NFSD: Do not send CB_RECALL_ANY to NFSv4.0 clients Chuck Lever
2026-08-12 14:59 ` [PATCH v2 2/4] NFSD: Count the delegations held by each client Chuck Lever
2026-08-12 14:59 ` [PATCH v2 3/4] NFSD: Name directory delegations in the CB_RECALL_ANY type mask Chuck Lever
2026-08-12 14:59 ` [PATCH v2 4/4] NFSD: Send a meaningful CB_RECALL_ANY keep count Chuck Lever
2026-08-12 17:36 ` Jeff Layton [this message]

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=a2cfbd0dc381f3ebb40f5702be83c0ae4fd693c7.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=cel@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.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 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.