Fwd: [patch] bufmgr Half state CAS

---------- Forwarded message ---------
From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
Date: Sat, Oct 10, 2026, 22:39
Subject: Re: [patch] bufmgr Half state CAS
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>

Hi Heikki, thank you for the attention

On Fri, Oct 9, 2026 at 11:40 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> 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.