Re: Thinking about breaking up the BufMgrLock

>Neil Conway writes
> We're only concerned with a buffer's access recency when it is on the
> free list, right? (That is certainly true with naive LRU; I confess I
> haven't had a chance to grok the 2Q paper yet). If so:

> - we need only update a pinned buffer's LRU position when its shared
> refcount drops to zero, not on every ReleaseBuffer()
>
> This means we need to acquire the LRU lock once for each
> acquire/release
> pair on a previously-unpinned buffer (rather than twice, if we had to
> acquire the LRU lock on acquire as well). Not sure if that's enough to
> remove the contention problem; on the plus side, it doesn't change the
> actual behavior of the replacement policy.

This is a fantastic idea, well done.

> - when we need to fault in a page from disk, acquire the LRU lock and
> select a buffer for replacement. At this point we can do some physical
> cleanup of the free list, by removing buffers with a non-zero refcount
> from the free list. We can do this cleanup relatively cheaply now,
> because we had to acquire the LRU lock anyway, and this is
> the slow path
> of ReadBuffer(). This work might also be done by the bgwriter
> (removing
> clean but pinned buffers from close to the LRU of the free list).

I'm not sure I understand this. Removing clean buffers doesn't cost
much, its the removal of dirty ones that cost, surely? There is no work
to remove a clean buffer.

Best Regards, Simon Riggs