From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Ants Aasma <ants(at)cybertec(dot)at>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Page replacement algorithm in buffer cache |
Date: | 2013-03-22 20:16:18 |
Message-ID: | 29748.1363983378@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Merlin Moncure <mmoncure(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2013-03-22 20:22:16 | Re: Page replacement algorithm in buffer cache |
Previous Message | Merlin Moncure | 2013-03-22 20:09:09 | Re: Page replacement algorithm in buffer cache |