On Sun, Mar 24, 2013 at 9:29 AM, Atri Sharma <atri.j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
