On Sun, Mar 24, 2013 at 9:29 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
>> I'll have to take a look. Removing *all spinning* from from page
>> allocation though feels like it might be worthwhile to test (got to
>> give some bonus points for being a very local change and simple to
>> implement). I wonder if with more shared buffers you tend to sweep
>> more buffers per allocation. (IIRC Jeff J was skeptical of that).
>
> Replacing the spinning with TAS for buffer header sounds like a good idea.
Well, TAS is exactly what spinlocks are spinning on. Plain old
unlocked read-modify-write should be good enough for clock sweep usage
count update with the header lock taken only when we decide to try and
evict something. The data raciness will mean a higher or lower than
normal usage count when two an increment and decrement race each
other. The race is only likely for buffers with high contention. If we
use the value calculated locally to decide on eviction, the highly
used buffers where this is likely will get at least one clock sweep
cycle of grace time. If they are indeed highly used it's likely that
someone will manage to bump the usage_count in the meanwhile. If they
are not hot, a rare speedup or delay in eviction won't matter much.
Getting rid of memory barriers associated with locking in the clock
sweep will pipeline the loads and stores and so should bring on a good
performance increase for scanning large swathes of buffer headers.
Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de