| От | Qingqing Zhou |
|---|---|
| Тема | Re: Spinlocks, yet again: analysis and proposed patches |
| Дата | |
| Msg-id | e6qidu$r69$1@news.hub.org обсуждение |
| Ответ на | Re: Spinlocks, yet again: analysis and proposed patches (Simon Riggs <simon@2ndquadrant.com>) |
| Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> wrote > > 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. > Exactly, this is one way -- if we make LWLOCK_PADDED_SIZE big enough, we can assure that one lwlock one cacheline. If so, maybe we should plug in a check like LMBench in ./configure to guess out current cacheline size. But this way looks like overkill -- a compromise is to pad only some of the LWLocks big enough but not all (for example, the buffer content lock array). Regards, Qingqing
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера