Re: [PATCH v2] KEYS: key_garbage_collector(): process in chunks

[Jarkko Sakkinen <jarkko@kernel.org>]

On Wed, Oct 28, 2026 at 05:15:44AM +0200, Jarkko Sakkinen wrote:
> On Wed, Oct 28, 2026 at 04:53:04AM +0200, Jarkko Sakkinen wrote:
> > key_garbage_collector() has a design that is not resistant enough for
> > workqueue lockups. The duration scales up relative to the number of items
> > in the serial tree, which causes a reoccuring theme of being guilty of
> > causing workqueue lockups.
> > 
> > Resolve the problem by processing in chunks:
> > 
> > 1. Declare a static variable key_gc_work, which owns the garbage collection
> >    in-flight state, and key_schedule_gc_work() for re-scheduling the work.
> > 2. Define KEY_GC_CHUNK_SIZE, set to 1024 keys, as the bound for the number
> >    of items scanned and destroyed.
> > 3. Define KEY_GC_DESTROYING to mark resume to destruction without repeating
> >    the RCU grace period. Drain the graveyard before advancing key-type
> >    reaping.
> > 4. Define KEY_GC_REAP_REQUESTED for preserving full-pass requests across
> >    the continuations.
> > 
> > The following test was performed:
> > 
> > 1. Add 499995 "unused" keys.
> > 2. Add 499994 "expiring" keys i.e., keys with expiration times.
> > 3. Clear the first keyring.
> > 4. Wait for the timeouts expire from the second.
> > 
> > When tested with QEMU using x86-64 and aarch64 (emulated) architectures the
> > elapsed the results were the following:
> > 
> > - x86-64: chunk max: 125 ms, total time increase: 5%
> > - aarch64: chunk max: 235 ms, total time increase: 6%
> > 
> > Tests were performed using a laptop with AMD 4650U (Zen 2 uarch) CPU.
> > 
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> The big picture here is that e.g., [1] might be a good idea (or might
> not) but it would be a mistake to apply the patch before the data flow
> overall has some sanity in it.
> 
> And with, I think, somewhat pretty modest changes the state has been
> put in a nice box :-) Much better shovelling position I'd say.
> 
> [1] https://lore.kernel.org/keyrings/20261026031219.2627968-1-jarkko@kernel.org/

I'm rewriting the benchmark in C using eBPF probe and make it available
later on. Probably metrics change a bit (i.e., become more accurate) as
it was previously written with bash and perf.

Br, Jarkko