Re: LWLock cache line alignment

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: LWLock cache line alignment
Дата
Msg-id KGEFLMPJFBNNLNOOOPLGOEDNCIAA.simon@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: LWLock cache line alignment  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: LWLock cache line alignment  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: LWLock cache line alignment  (Kenneth Marshall <ktm@it.is.rice.edu>)
Список pgsql-hackers
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us] wrote
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > It looks like padding out LWLock struct would ensure that
> each of those
> > were in separate cache lines?
>
> I've looked at this before and I think it's a nonstarter;
> increasing the
> size of a spinlock to 128 bytes is just not reasonable.
> (Remember there
> are two per buffer.)

Well, the performance is unreasonably poor, so its time to do something,
which might if it is unreasonable for the general case would need to be
port specific.

Also, there's no evidence it would actually help
> anything, because the contention we have been able to measure
> is on only
> one particular lock (BufMgrLock) anyway.  But feel free to
> try it to see
> if you can see a difference.

Well, the Wierd Context Switching issue isn't normal contention, which I
agree is stacked up against BufMgrLock.

Overlapping cache lines doesn't cause measurable user space contention,
just poor performance when the delay for cache-spoil, refetch is
required many times more than the minimum (ideal).

I'm thinking that the 128 byte cache line on Intel is sufficiently
higher than the 64 byte cache line on AMD to tip us into different
behaviour at runtime.

Best Regards, Simon Riggs



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: LWLockRelease
Следующее
От: Tom Lane
Дата:
Сообщение: Re: LWLock cache line alignment