Re: Scaling shared buffer eviction - Mailing list pgsql-hackers

<div dir="ltr">On Tue, Aug 5, 2014 at 9:21 PM, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br />><br />> Incidentally, while I
generallythink your changes to the locking regimen in StrategyGetBuffer() are going in the right direction, they need
significantcleanup.  Your patch adds two new spinlocks, freelist_lck and victimbuf_lck, that mostly but not-quite
replaceBufFreelistLock, and you've now got StrategyGetBuffer() running with no lock at all when accessing some things
thatused to be protected by BufFreelistLock; specifically, you're doing StrategyControl->numBufferAllocs++ and
SetLatch(StrategyControl->bgwriterLatch)without any locking.  That's not OK.  I think you should get rid of
BufFreelistLockcompletely and just decide that freelist_lck will protect everything the freeNext links, plus everything
inStrategyControl except for nextVictimBuffer.  victimbuf_lck will protect nextVictimBuffer and nothing else.<br />
><br/>> Then, in StrategyGetBuffer, acquire the freelist_lck at the point where the LWLock is acquired today.
 IncrementStrategyControl->numBufferAllocs; save the values of StrategyControl->bgwriterLatch; pop a buffer off
thefreelist if there is one, saving its identity.  Release the spinlock.  Then, set the bgwriterLatch if needed.  In
thefirst loop, first check whether the buffer we previously popped from the freelist is pinned or has a non-zero usage
countand return it if not, holding the buffer header lock.  Otherwise, reacquire the spinlock just long enough to pop a
newpotential victim and then loop around.<br /> ><br /><br />Today, while working on updating the patch to improve
locking<br/>I found that as now we are going to have a new process, we need<br />a separate latch in StrategyControl to
wakeupthat process.<br />Another point is I think it will be better to protect<br /> StrategyControl->completePasses
withvictimbuf_lck rather than<br />freelist_lck, as when we are going to update it we will already be<br />holding the
victimbuf_lckand it doesn't make much sense to release<br />the victimbuf_lck and reacquire freelist_lck to update
it.<br/><br />I thought it is better to mention about above points so that if you have<br />any different thoughts
aboutit, then it is better to discuss them now<br />rather than after I take performance data with this locking
protocol.<br/><br />With Regards,<br />Amit Kapila.<br />EnterpriseDB: <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></div>