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@xxxxxxxxxx>
