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 <[email protected]> > > 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/[email protected]/
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
