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

[Jarkko Sakkinen <jarkko@kernel.org>]

On Thu, Oct 29, 2026 at 04:33:10PM +0200, Jarkko Sakkinen wrote:
> On Thu, Oct 29, 2026 at 04:07:05PM +0200, Jarkko Sakkinen wrote:
> > keygcbench results without the patch:
> > 
> > unused:   min=3016.754 avg=11859.097 max=28667.645 var=141391574.712
> > expired:  min=0.015 avg=12758.165 max=21516.237 var=85158284.646
> > combined: min=0.015 avg=12308.631 max=28667.645 var=113477010.596
> > 
> > keygcbench results with the patch:
> > 
> > unused:   min=0.225 avg=13.991 max=853.100 var=858.700
> > expired:  min=0.016 avg=30.442 max=2791.695 var=14187.539
> > combined: min=0.016 avg=19.249 max=2791.695 var=5177.436
> 
> I personally would optimize all-in for variance because:
> 
> 1. It is insignificant drawback for any practical keyring workload
>    if the total time increases slightly.
> 2. Latency peaks are a signifiant drawback for any possible latency
>    sensitive workload running in the system.
> 
> What I'm doing now is to find sweet spot chunk size below 1024 where
> variances reaches its lowest value.
> 
> The latency part makes this change more valuable than focusing on
> only on the regression itself.

The best block size 1 and this was actually my guess. Just in case I ran
the benchmark three times for each 11 block sizes.

It is simple refactor to do. I simply substitute KEY_GC_BLOCK_SIZE with
1 and carefully refactor the constant out.

I think that converging to the correct solution through this route was
worth of the additional trouble because at least now properly sanity
checked.

Br, Jarkko