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
