From: Tom Lane <tgl@sss.pgh.pa.us>
To: Merlin Moncure <mmoncure@gmail.com>
cc: Atri Sharma <atri.jiit@gmail.com>, Greg Stark <stark@mit.edu>,
	Ants Aasma <ants@cybertec.at>, Amit Kapila <amit.kapila@huawei.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Page replacement algorithm in buffer cache
In-reply-to: 
 <CAHyXU0yKC-HWk9hhBjUCPsnPMqhskvu_MEqB2cvmRu0d0+BsCw@mail.gmail.com>
References: 
 <CAOeZVic4HikhmzVD=ZP4JY9g8PgpyiQQOXOELWP=kR+=H1Frgg@mail.gmail.com>
	<514bf302.84d5440a.43f2.ffffe411SMTPIN_ADDED_BROKEN@mx.google.com>
	<08BBC126-D375-4743-B9A6-D1320D05D5C7@gmail.com>
	<514c3395.487a420a.28d1.764eSMTPIN_ADDED_BROKEN@mx.google.com>
	<CAOeZVifZ89tOtcKeC6C2917sVfSyR3xiMenorg8sNR2+y2W=Wg@mail.gmail.com>
	<CA+CSw_se74iDCLswBfF7_Rd1542nhyw-YSmQ+OqDwEzu0rZkSw@mail.gmail.com>
	<3985.1363960959@sss.pgh.pa.us>
	<CAM-w4HM2A0rAGN-KRyDQfcH+8YsDvCJ4x=XYAsS+G2kp56qOjQ@mail.gmail.com>
	<CAOeZVicGOGQZJZKFXFYjm0wDFA63+7cmzzGQ63nP+165-5qiLQ@mail.gmail.com>
	<CAHyXU0xMFvr2eiR+2Lv=dj+UON+muei_pjbUP2BMetiR-UTASw@mail.gmail.com>
	<29181.1363981925@sss.pgh.pa.us>
	<CAHyXU0yKC-HWk9hhBjUCPsnPMqhskvu_MEqB2cvmRu0d0+BsCw@mail.gmail.com>
Comments: In-reply-to Merlin Moncure <mmoncure@gmail.com>
	message dated "Fri, 22 Mar 2013 15:09:09 -0500"
Date: Fri, 22 Mar 2013 16:16:18 -0400
Message-ID: <29748.1363983378@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Merlin Moncure <mmoncure@gmail.com> 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.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers