Re: Page replacement algorithm in buffer cache
От | Bruce Momjian |
---|---|
Тема | Re: Page replacement algorithm in buffer cache |
Дата | |
Msg-id | 20130401203249.GA11288@momjian.us обсуждение исходный текст |
Ответ на | Re: Page replacement algorithm in buffer cache (Merlin Moncure <mmoncure@gmail.com>) |
Ответы |
Re: Page replacement algorithm in buffer cache
|
Список | pgsql-hackers |
On Mon, Apr 1, 2013 at 11:55:07AM -0500, Merlin Moncure wrote: > > In fact, BufFreelistLock is really misnamed, because for the most > > part, the "free list" as we implement is going to be empty. What the > > BufFreelistLock is really doing is serializing the process of scanning > > for a free buffer. I think THAT is the problem. If we could arrange > > things so as to hold BufFreelistLock only for the amount of time > > needed to remove a buffer from a freelist ... we'd probably buy > > ourselves quite a bit. > > right. I'm imaging a buffer scan loop that looks something like > (uncompiled, untested) this. "TryLockBufHdr" does a simple TAS > without spin, returning the lock state (well, true if it acquired the > lock). usage_count is specifically and deliberately adjusted without > having a lock on the buffer header (this would require some careful > testing and possible changes elsewhere): TAS does a CPU 'lock' instruction which affects the cpu cache. Why not just read the value with no lock? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: