On 8 Oct 2022, at 23:26, Gleb Smirnoff wrote:
> On Sat, Oct 08, 2022 at 04:41:29PM +0000, Kristof Provost wrote:
> K> commit 133935d26f20c0b9c433da9a2b32bcbe562bc2c5
> K> Author: Kristof Provost <[email protected]>
> K> AuthorDate: 2022-10-07 17:17:06 +0000
> K> Commit: Kristof Provost <[email protected]>
> K> CommitDate: 2022-10-08 16:27:29 +0000
> K>
> K> pf: atomically increment state ids
> K>
> K> Rather than using a per-cpu state counter, and adding in the CPU id we
> K> can atomically increment the number.
> K> This has the advantage of removing the assumption that the CPU ID fits
> K> in 8 bits.
> K>
> K> Event: Aberdeen Hackathon 2022
> K> Reviewed by: mjg
> K> Differential Revision: https://reviews.freebsd.org/D36915
>
> This adds an atomic operation on a single word on a state creation :(
> Previously two state creations could run in parallel without negatively
> affecting each other.
>
Slightly related: has anyone ever run a benchmark on state creation?
All of the benchmarking I’ve done so far focussed on traffic rates, so state
lookups rather than state creation. (Which I think is the more important
metric, but obviously we don’t want to overly pessimise state creation either.)
This change does buy us “we actually work on > 256 CPU machines”, and I
strongly suspect this isn’t actually going to be the bottleneck on state
creation either. Especially not once mjg improves unr64.
Best regards,
Kristof
