Re: git: 133935d26f20 - main - pf: atomically increment state ids
- In reply to: Gleb Smirnoff : "Re: git: 133935d26f20 - main - pf: atomically increment state ids"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 09 Oct 2022 19:46:20 UTC
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 <kp@FreeBSD.org> > K> AuthorDate: 2022-10-07 17:17:06 +0000 > K> Commit: Kristof Provost <kp@FreeBSD.org> > 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