Re: MultiXact\SLRU buffers configuration - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: MultiXact\SLRU buffers configuration
Date
Msg-id 28051640513399@vla1-36b7415cbc1b.qloud-c.yandex.net
Whole thread Raw
In response to Re: MultiXact\SLRU buffers configuration  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: MultiXact\SLRU buffers configuration  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers

>> 8 апр. 2021 г., в 15:22, Thomas Munro <thomas.munro@gmail.com> написал(а):
>>
> I have one more idea inspired by CPU caches.
> Let's make SLRU n-associative, where n ~ 8.
> We can divide buffers into "banks", number of banks must be power of 2.
> All banks are of equal size. We choose bank size to approximately satisfy user's configured buffer size.
> Each page can live only within one bank. We use same search and eviction algorithms as we used in SLRU, but we only
needto search\evict over 8 elements.
 
> All SLRU data of a single bank will be colocated within at most 2 cache line.
> 
> I did not come up with idea how to avoid multiplication of bank_number * bank_size in case when user configured 31337
buffers(any number that is radically not a power of 2).
 

We can avoid this multiplication by using gapped memory under SLRU page_statuses, but from my POV here complexity does
notworth possible performance gain.
 

PFA rebase of the patchset. Also I've added a patch to combine page_number, page_status, and page_dirty together to
touchless cachelines.
 

Best regards, Andrey Borodin.


Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: correct the sizes of values and nulls arrays in pg_control_checkpoint
Next
From: Justin Pryzby
Date:
Subject: Re: Inconsistent ellipsis in regression test error message?