On Tue, Apr 15, 2014 at 11:27 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Wed, Apr 16, 2014 at 5:00 AM, Peter Geoghegan <p...@heroku.com> wrote: >> On Tue, Apr 15, 2014 at 3:59 PM, Ants Aasma <a...@cybertec.at> wrote: >>> There's a paper on a non blocking GCLOCK algorithm, that does lock >>> free clock sweep and buffer pinning[7]. If we decide to stay with >>> GCLOCK it may be interesting, although I still believe that some >>> variant of buffer nailing[8] is a better idea, my experience shows >>> that most of the locking overhead is cache line bouncing ignoring the >>> extreme cases where our naive spinlock implementation blows up. >> >> You might be right about that, but lets handle one problem at a time. >> Who knows what the bottleneck will end up being if and when we address >> the naivety around frequency? I want to better characterize that >> problem first. > > Just to summarize you about the previous discussion and the > improvements that we decided to do in this area based on feedback > are as follows: > > 1. Bgwriter needs to be improved so that it can help in reducing > usage count and finding next victim buffer (run the clock sweep > and add buffers to the free list). > 2. SetLatch for bgwriter (wakeup bgwriter) when elements in freelist > are less. > 3. Split the workdone globallock (Buffreelist) in StrategyGetBuffer > (a spinlock for the freelist, and an lwlock for the clock sweep). > Here we can try to make it lock free based on atomic ops as > well. > 4. Bgwriter needs to be more aggressive, logic based on which it > calculates how many buffers it needs to process needs to be > improved. > 5. Contention around buffer mapping locks. > 6. Cacheline bouncing around the buffer header spinlocks, is there > anything we can do to reduce this? > 7. Choose Optimistically used buffer in StrategyGetBuffer(). > 8. Don't bump the usage count every time buffer is pinned.
What about: 9. Don't wait on locked buffer in the clock sweep. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
