Re: [PATCH] Batched clock sweep to reduce cross-socket atomic contention

Hi,

On 2026-07-22 19:09:18 +0300, Ants Aasma wrote:
> Generally agreed, but I wanted to understand one point a bit better.
>
> On Wed, 22 Jul 2026 at 18:29, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > - I don't think the hit ratio is an all that interesting way to evaluate the
> > cache replacement, particularly for something like pgbench -S. It really
> > matters *which* buffers are evicted.
>
> Is that only because a single bad eviction could cause multiple
> backends to wait for an I/O?

Mainly that, yea. If you evict, in the most extreme case, an inner index page,
it's quite likely that you cause multiple backends to wait once you have a
decent amount of concurrency. Even with index leaf pages that's not
unlikely. Whereas it's rather unlikely for a heap page, just due to the larger
number of those.

It's probably less of an issue with local NVMe latencies, but once you have
cloud storage involved...

> To me, a high probability of multiple accesses within one disk latency would
> imply that the buffer is really hot and the eviction algorithm would have to
> be really terrible to evict it.

I think it won't happen that often if the working set is close to s_b, because
the replacement rate is relatively low. But if the working set is considerably
larger than s_b + kernel page cache and you have a non-uniform access model
(so there's a decent number of accesses even to a small number of heap pages),
it's not hard to have a replacement algorithm that can't distinguish between
the importance of the index pages vs heap pages.

> Of course with prefetching, distinguisghing prefetched misses from
> synchronous misses is very much important.

Indeed. One thing, in the context of the current buffer replacement model, I
have been wondering about, is cabining how far async reads can increase the
usage count. Differentiating that would make it more likely that synchronously
needed buffers survive for longer.

Greetings,

Andres Freund