| От | Tom Lane |
|---|---|
| Тема | Re: Spinlocks, yet again: analysis and proposed patches |
| Дата | |
| Msg-id | 16503.1150338529@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Spinlocks, yet again: analysis and proposed patches ("Qingqing Zhou" <zhouqq@cs.toronto.edu>) |
| Список | pgsql-hackers |
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
>>> One thing we tried in February was padding out the statically defined
>>> locks with dummy lock definitions in the enum.
> Has this been done? See the LWLOCK_PADDED_SIZE macro in code.
Not really --- that patch was intended to ensure that LWLocks don't
unnecessarily cross two cache lines. It doesn't ensure that two
different LWLocks aren't sharing a cache line. You could do that
by increasing LWLOCK_PADDED_SIZE to the cache line size for your
hardware, if you know what that is.
I think a more effective answer might be to twiddle the order of
"enum LWLockId" items so that the most heavily used LWLocks aren't
close together. Haven't looked into it though.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера