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
