| Message ID | 20241119004928.3245873-1-neilb@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | nfsd: allocate/free session-based DRC slots on demand | expand |
On Tue, 2024-11-19 at 11:41 +1100, NeilBrown wrote: > Here is v2 of my series for on-demand allocation and freeing of session DRC slots. > > - Now uses an xarray to store slots, and the limit is raised to 2048 > - delays retiring a slot until the client has confirmed that it isn't > using it as described in RFC: > > The replier SHOULD retain the slots it wants to retire until the > requester sends a request with a highest_slotid less than or equal > to the replier's new enforced highest_slotid. > > - When a retired slot is used, allow the seqid to be the next in sequence > as required by the RFC: > > Each time a slot is reused, the request MUST specify a sequence > ID that is one greater than that of the previous request on the > slot. > > or "1" as (arguably) allowed by the RFC: > > The first time a slot is used, the requester MUST specify a > sequence ID of one > I thought that the conclusion of the IETF discussion was that we should reset this to 1. It'd be ideal to just do that, as then we wouldn't need NFSD4_SLOT_REUSED. Are there any clients that expect to reuse the old seqid in this situation? I know the Linux client doesn't. Do Solaris or FreeBSD? > - current slot allocation is now reported in /proc/fs/nfsd/clients/*/info > > This has been tested with highly aggressive shrinker settings: > nfsd_slot_shrinker->seeks = 0; > nfsd_slot_shrinker->batch = 2; > > and with periodic "echo 3 > drop_caches". The slot count drops as > expected and then increases again. > This is really great work, Neil! -- Jeff Layton <jlayton@kernel.org>
On Wed, 20 Nov 2024, Jeff Layton wrote: > On Tue, 2024-11-19 at 11:41 +1100, NeilBrown wrote: > > Here is v2 of my series for on-demand allocation and freeing of session DRC slots. > > > > - Now uses an xarray to store slots, and the limit is raised to 2048 > > - delays retiring a slot until the client has confirmed that it isn't > > using it as described in RFC: > > > > The replier SHOULD retain the slots it wants to retire until the > > requester sends a request with a highest_slotid less than or equal > > to the replier's new enforced highest_slotid. > > > > - When a retired slot is used, allow the seqid to be the next in sequence > > as required by the RFC: > > > > Each time a slot is reused, the request MUST specify a sequence > > ID that is one greater than that of the previous request on the > > slot. > > > > or "1" as (arguably) allowed by the RFC: > > > > The first time a slot is used, the requester MUST specify a > > sequence ID of one > > > > I thought that the conclusion of the IETF discussion was that we should > reset this to 1. It'd be ideal to just do that, as then we wouldn't > need NFSD4_SLOT_REUSED. I thought the conclusion was: I'm convinced. The next draft of rfc5661bis will address this issue. Until the issue is addressed I don't think it would be wise to preempt the result. > > Are there any clients that expect to reuse the old seqid in this > situation? I know the Linux client doesn't. Do Solaris or FreeBSD? I don't know. But I tend to code the the spec, not to other clients. I still think the specs says Each time a slot is reused, the request MUST specify a sequence ID that is one greater than that of the previous request on the slot. and I don't see any good reason not to treat what we are doing here as "reuse". So I'm making a concession to the linux client and to you by allowing '1'. I'm still not convinced that it is a good idea. At best I'm convinced that the spec can be read to suggest that might be an option. Thanks, NeilBrown
Here is v2 of my series for on-demand allocation and freeing of session DRC slots. - Now uses an xarray to store slots, and the limit is raised to 2048 - delays retiring a slot until the client has confirmed that it isn't using it as described in RFC: The replier SHOULD retain the slots it wants to retire until the requester sends a request with a highest_slotid less than or equal to the replier's new enforced highest_slotid. - When a retired slot is used, allow the seqid to be the next in sequence as required by the RFC: Each time a slot is reused, the request MUST specify a sequence ID that is one greater than that of the previous request on the slot. or "1" as (arguably) allowed by the RFC: The first time a slot is used, the requester MUST specify a sequence ID of one - current slot allocation is now reported in /proc/fs/nfsd/clients/*/info This has been tested with highly aggressive shrinker settings: nfsd_slot_shrinker->seeks = 0; nfsd_slot_shrinker->batch = 2; and with periodic "echo 3 > drop_caches". The slot count drops as expected and then increases again. NeilBrown