Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UKWvm-0003gE-L7 for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2013 16:41:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UKWvm-0001dV-5R for pgsql-hackers@arkaria.postgresql.org; Tue, 26 Mar 2013 16:41:02 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UKWvl-0001dF-0k for pgsql-hackers@postgresql.org; Tue, 26 Mar 2013 16:41:01 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UKWvi-0000Ik-Qq for pgsql-hackers@postgresql.org; Tue, 26 Mar 2013 16:41:00 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1UKWve-00069z-3J; Tue, 26 Mar 2013 12:40:54 -0400 Date: Tue, 26 Mar 2013 12:40:54 -0400 From: Bruce Momjian To: Tom Lane Cc: Merlin Moncure , Atri Sharma , Greg Stark , Ants Aasma , Amit Kapila , PostgreSQL-development Subject: Re: Page replacement algorithm in buffer cache Message-ID: <20130326164054.GD20871@momjian.us> References: <514c3395.487a420a.28d1.764eSMTPIN_ADDED_BROKEN@mx.google.com> <3985.1363960959@sss.pgh.pa.us> <29181.1363981925@sss.pgh.pa.us> <29748.1363983378@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29748.1363983378@sss.pgh.pa.us> User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -3.2 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On Fri, Mar 22, 2013 at 04:16:18PM -0400, Tom Lane wrote: > Merlin Moncure writes: > > I think there is some very low hanging optimization fruit in the clock > > sweep loop. first and foremost, I see no good reason why when > > scanning pages we have to spin and wait on a buffer in order to > > pedantically adjust usage_count. some simple refactoring there could > > set it up so that a simple TAS (or even a TTAS with the first test in > > front of the cache line lock as we done automatically in x86 IIRC) > > could guard the buffer and, in the event of any lock detected, simply > > move on to the next candidate without messing around with that buffer > > at all. This could construed as a 'trylock' variant of a spinlock > > and might help out with cases where an especially hot buffer is > > locking up the sweep. This is exploiting the fact that from > > StrategyGetBuffer we don't need a *particular* buffer, just *a* > > buffer. > > Hm. You could argue in fact that if there's contention for the buffer > header, that's proof that it's busy and shouldn't have its usage count > decremented. So this seems okay from a logical standpoint. > > However, I'm not real sure that it's possible to do a conditional > spinlock acquire that doesn't create just as much hardware-level > contention as a full acquire (ie, TAS is about as bad whether it > gets the lock or not). So the actual benefit is a bit less clear. Could we view the usage count, and if it is 5, and if there is someone holding the lock, we just ignore the buffer and move on to the next buffer? Seems that could be done with no locking. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers