From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Atri Sharma <atri.jiit@gmail.com>
Cc: Greg Stark <stark@mit.edu>
Cc: Ants Aasma <ants@cybertec.at>
Cc: Amit Kapila <amit.kapila@huawei.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Page replacement algorithm in buffer cache
Date: Tue, 26 Mar 2013 12:40:54 -0400
Message-ID: <20130326164054.GD20871@momjian.us> (raw)
In-Reply-To: <29748.1363983378@sss.pgh.pa.us>
References: <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>
<29748.1363983378@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On Fri, Mar 22, 2013 at 04:16:18PM -0400, Tom Lane wrote:
> 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.
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 <bruce@momjian.us> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, tgl@sss.pgh.pa.us, mmoncure@gmail.com, atri.jiit@gmail.com, stark@mit.edu, ants@cybertec.at, amit.kapila@huawei.com
Subject: Re: Page replacement algorithm in buffer cache
In-Reply-To: <20130326164054.GD20871@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox