On 17.01.2012 14:38, Peter Geoghegan wrote:
> On 17 January 2012 11:24, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>> In the patch I sent, I did rearrange the sleeping logic. I think it's more
>> readable the way it is now.
>
> I have no objection to either your refinement of the sleeping logic,
> nor that you moved some things in both the existing code and my patch
> so that they occur when no spinlock is held.
Ok, committed with some further cleanup.
Do you think the docs need to be updated for this, and if so, where? The
only place I found in the docs that speak about how the bgwriter works
is in config.sgml, where bgwriter_delay is described. Want to suggest an
update to that?
> Should I proceed with a benchmark on V3, so that we can get this
> committed? I imagine that a long pgbench-tools run is appropriate,
> (after all, it was used to justify the re-write of the BGWriter for
> 8.3) at various scale factors, from smallish to quite large.
I did some testing on this, with a highly artificial test case that
dirties pages in shared_buffers as fast as possible. I tried to make it
a worst-case scenario, see attached script. I tested this with a 32-core
HP Itanium box, and on my 2-core laptop, and didn't see any measurable
slowdown from this patch. So I think we're good.
If setting the latch would become a contention issue, there would be a
pretty easy solution: only try to do it every 10 or 100 dirtied pages,
for example. A few dirty pages in the buffer cache don't mean anything,
as long as we kick the bgwriter in a fairly timely fashion when a larger
burst of activity begins.
BTW, do you have some sort of a test setup for these power-saving
patches, to actually measure the effect on number of interrupts or
electricity use? Fewer wakeups should be a good thing, but it would be
nice to see some figures to get an idea of how much progress we've done
and what still needs to be done.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
