>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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
