Re: Should we cacheline align PGXACT?
От | Craig Ringer |
---|---|
Тема | Re: Should we cacheline align PGXACT? |
Дата | |
Msg-id | CAMsr+YGEN_9BdTyc2ep92HqrLXUOmpGp2QfGV=9MeV6A=__o5A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should we cacheline align PGXACT? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Should we cacheline align PGXACT?
|
Список | pgsql-hackers |
On 22 August 2016 at 10:40, Andres Freund <andres@anarazel.de> wrote:
On 2016-08-19 09:46:12 -0400, Tom Lane wrote:
> Alexander Korotkov <a.korotkov@postgrespro.ru> writes:
> > originally this idea was proposed by Andres Freund while experimenting with
> > lockfree Pin/UnpinBuffer [1].
> > The patch is attached as well as results of pgbench -S on 72-cores
> > machine. As before it shows huge benefit in this case.
>
> That's one mighty ugly patch.
My version of it was only intended to nail down some variability on the
pgpro machine, it wasn't intended for submission.
> Can't you do it without needing to introduce the additional layer of
> struct nesting?
If we required support for anonymous unions, such things would be a lot
easier to do. That aside, the only alternative seems tob e hard-coding
padding space - which probably isn't all that un-fragile either.
Somewhat naïve question from someone with much less clue about low level cache behaviour trying to follow along: given that we determine such padding at compile time, how do we ensure that the cacheline size we're targeting is right at runtime? Or is it safe to assume that using 16 bytes so we don't cross cache line boundaries is always helpful, whether we have 4 PGXACT entries (64 byte line) or some other number per cacheline?
--
В списке pgsql-hackers по дате отправления: