From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Andrey M. Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
Date: Fri, 17 Nov 2023 13:46:29 +0100
Message-ID: <202311171246.zyuurxvs3oqu@alvherre.pgsql> (raw)
In-Reply-To: <CAFiTN-ubCKEFzeZji0Frv_7MdhAR4YxY91udqHMQ=DHViy7QnQ@mail.gmail.com>
In SlruSharedData, a new comment is added that starts:
"Instead of global counter we maintain a bank-wise lru counter because ..."
You don't need to explain what we don't do. Just explain what we do do.
So remove the words "Instead of a global counter" from there, because
they offer no wisdom. Same with the phrase "so there is no point to ...".
I think "The oldest page is therefore" should say "The oldest page *in
the bank* is therefore", for extra clarity.
I wonder what's the deal with false sharing in the new
bank_cur_lru_count array. Maybe instead of using LWLockPadded for
bank_locks, we should have a new struct, with both the LWLock and the
LRU counter; then pad *that* to the cacheline size. This way, both the
lwlock and the counter come to the CPU running this code together.
Looking at SlruRecentlyUsed, which was a macro and is now a function.
The comment about "multiple evaluation of arguments" no longer applies,
so it needs to be removed; and it shouldn't talk about itself being a
macro.
Using "Size" as type for bank_mask looks odd. For a bitmask, maybe it's
be more appropriate to use bits64 if we do need a 64-bit mask (we don't
have bits64, but it's easy to add a typedef). I bet we don't really
need a 64 bit mask, and a 32-bit or even a 16-bit is sufficient, given
the other limitations on number of buffers.
I think SimpleLruReadPage should have this assert at start:
+ Assert(LWLockHeldByMe(SimpleLruGetSLRUBankLock(ctl, pageno)));
Do we really need one separate lwlock tranche for each SLRU?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, dilipbalaut@gmail.com, x4mmm@yandex-team.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock
In-Reply-To: <202311171246.zyuurxvs3oqu@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox