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

[Jarkko Sakkinen <jarkko@kernel.org>]

On Thu, Oct 29, 2026 at 06:45:19PM +0200, Jarkko Sakkinen wrote:
> 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.

Taking this back! It has 133% total time increase :-) So yeah constant
is required. I have all eleven (x3 each) available so I pick something
more appropriate (more like 13% at most).

Br, Jarkko