---------- Forwarded message --------- From: Alexandre Felipe <[email protected]> Date: Sat, Oct 10, 2026, 22:39 Subject: Re: [patch] bufmgr Half state CAS To: Heikki Linnakangas <[email protected]>
Hi Heikki, thank you for the attention On Fri, Oct 9, 2026 at 11:40 PM Heikki Linnakangas <[email protected]> wrote: > On 08/10/2026 23:03, Alexandre Felipe wrote: > > Currently Buffer header state is a 64-bit, but it is conceptually a bit > > field structure. > > The CAS loops care about only some of those bits, however by operating > > on a 64-bit structure unrelated field changes will cause a retry. > > > > The atomic operations don't support a comparison mask, but in this case > > we can at least CAS 32-bit, low and high half separately, reducing the > > likelihood > > of retrial. > > Got benchmarks? See attached, running on top of 10cc5aa96a6 I got clients base patched 1 3251.2 3221.3 8 2592.2 3979.0 *+53.5%* With 1 CPU there can still benefit a little bit the fast path on BufUnlockEx, However, that can add some cost for the cases where set_bits is not constant and the compiler would emit an extra branch. With many CPUs is where it really helps, e.g. one backend trying to lock while another is trying to unpin the same buffer. To be honest, I wasn't confident that this would show up on benchmarks, so I didn't bother to try. I wouldn't be surprised if this was even slower. > Do you see any mechanism by which it could become slower? I can see only one: In UnlockBufHdrExt, if the branches are not eliminated by the compiler. And I can can see one case in TerminateBufferIO where it is not possible.
run-half-state.sh
Description: Bourne shell script
