StrategyGetBuffer questions

In this sprawling thread on scaling issues [1], the topic meandered
into StrategyGetBuffer() -- in particular the clock sweep loop.  I'm
wondering:

*) If there shouldn't be a a bound in terms of how many candidate
buffers you're allowed to skip for having a non-zero usage count.
Whenever an unpinned usage_count>0 buffer is found, trycounter is
reset (!) so that the code operates from point of view as it had just
entered the loop.  There is an implicit assumption that this is rare,
but how rare is it?

*) Shouldn't StrategyGetBuffer() bias down usage_count if it finds
itself examining too many unpinned buffers per sweep?

*) Since the purpose of usage_count is to act on advisory basis to
keep recently/frequently accessed buffers from being discarded, is it
really necessary to rigorously guard the count with a spinlock?  If a
++ or -- operation on the value gets missed here or there, how big of
a deal is it really?

Right now the code is going:    LockBufHdr(buf);    if (buf->refcount == 0)    {        if (buf->usage_count > 0)
{            buf->usage_count--;            trycounter = NBuffers;        }        else        {            /* Found a
usablebuffer */            if (strategy != NULL)                AddBufferToRing(strategy, buf);            return buf;
     }    }
 

What if the spinlock was deferred to *after* the initial examination
of the pin refcount.  Naturally, if we decided the buffer was
interesting we'd need to lock the header and retest refcount == 0 to
make sure nobody got to the buffer before us.  In the unlikely event
it was set we'd immediately unlock the header and loop.

That way we get to decrement usage_count and loop without having to
have ever acquired a spinlock on the header.  Point being: this would
tighten the clock sweep loop considerably if it ever happens that
there were a lot of buffers with usage_count > 0 to wade through
before getting a candidate, at the cost of usage_count being 100%
deterministic. Is that harmless though?  If it was, or it could be
reasonably be put in, would this positively impact cases that are
bound by the free list lock?

merlin

http://postgresql.1045698.n5.nabble.com/High-SYS-CPU-need-advise-td5732045.html