Re: Performance under contention

Поиск
Список
Период
Сортировка
От Dave Crooke
Тема Re: Performance under contention
Дата
Msg-id AANLkTin6k6drOzrcJKSNNa=aVDAi8b5pG29V3G4whh4x@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance under contention  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Hi Tom

I suspect I may be missing something here, but I think it's a pretty universal truism that cache lines are aligned to power-of-2 memory addresses, so it would suffice to ensure during setup that the lower order n bits of the object address are all zeros for each critical object; if the malloc() routine being used doesn't support that, it could be done by allocating a slightly larger than necessary block of memory and choosing a location within that.

The value of n could be architecture dependent, but n=8 would cover everyone, hopefully without wasting too much RAM.

Cheers
Dave

On Tue, Dec 7, 2010 at 11:50 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

One thing that might be interesting, but that I don't know how to attack
in a reasonably machine-independent way, is to try to ensure that shared
and local data structures don't accidentally overlap within cache lines.
When they do, you pay for fighting the cache line away from another
processor even when there's no real need.

                       regards, tom lane

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Performance under contention
Следующее
От: Tom Polak
Дата:
Сообщение: Compared MS SQL 2000 to Postgresql 9.0 on Windows