Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock

On 30 Oct 2023, at 09:20, Dilip Kumar <dilipbalaut@gmail.com> wrote:

changed the logic of SlruAdjustNSlots() in 0002, such that now it
starts with the next power of 2 value of the configured slots and
keeps doubling the number of banks until we reach the number of banks
to the max SLRU_MAX_BANKS(128) and bank size is bigger than
SLRU_MIN_BANK_SIZE (8).  By doing so, we will ensure we don't have too
many banks

There was nothing wrong with having too many banks. Until bank-wise locks and counters were added in later patchsets.

Having hashtable to find SLRU page in the buffer IMV is too slow. Some comments on this approach can be found here [0].

I'm OK with having HTAB for that if we are sure performance does not degrade significantly, but I really doubt this is the case.

I even think SLRU buffers used HTAB in some ancient times, but I could not find commit when it was changed to linear search.

Maybe we could decouple locks and counters from SLRU banks? Banks were meant to be small to exploit performance of local linear search. Lock partitions have to be bigger for sure.