On Tue, Apr 15, 2014 at 11:27 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Wed, Apr 16, 2014 at 5:00 AM, Peter Geoghegan <pg@heroku.com> wrote:
>> On Tue, Apr 15, 2014 at 3:59 PM, Ants Aasma <ants@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