Re: Fix bank selection logic in SLRU - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Fix bank selection logic in SLRU
Date
Msg-id CAFiTN-vrosBekPSx2k1_CiuGL5W=HH6C4+e61PpK7kwo-ggZPQ@mail.gmail.com
Whole thread Raw
In response to Re: Fix bank selection logic in SLRU  ("Andrey M. Borodin" <x4mmm@yandex-team.ru>)
Responses Re: Fix bank selection logic in SLRU
List pgsql-hackers
On Tue, Dec 10, 2024 at 6:32 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
> > On 10 Dec 2024, at 15:39, Yura Sokolov <y.sokolov@postgrespro.ru> wrote:
> >
> > It is not critical bug, since it doesn't hurt correctness just performance. In worst case only one bank will be
used.
>
> Ugh... yeah. IMO the problem is that we do not have protection that rejects values that are not power of 2.
> If other values given system operates as if there are 2^(popcount(n)-1) banks. So if we just round down value to
nearestpower of 2 - we will help incorrectly configured systems to use proper amount of memory and keep performance of
properlyconfigured systems. 
>
> IMO doing modulo is not necessary. And hash function is pure waste of CPU cycles.


IIUC, we do check that it should be in multiple of bank size (i.e.)
which is multiple of 2, right?  Am I missing something?

/*
* Helper function for GUC check_hook to check whether slru buffers are in
* multiples of SLRU_BANK_SIZE.
*/
bool
check_slru_buffers(const char *name, int *newval)
{
/* Valid values are multiples of SLRU_BANK_SIZE */
if (*newval % SLRU_BANK_SIZE == 0)
return true;

GUC_check_errdetail("\"%s\" must be a multiple of %d", name,
SLRU_BANK_SIZE);
return false;
}



--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Andrey M. Borodin"
Date:
Subject: Re: Fix bank selection logic in SLRU
Next
From: wenhui qiu
Date:
Subject: Re: [PATCH] Support Int64 GUCs