Re: BGWriter latch, power saving

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BGWriter latch, power saving
Date: 2012-01-26 16:48:31
Message-ID: 4F2183DF.4050707@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17.01.2012 14:38, Peter Geoghegan wrote:
> On 17 January 2012 11:24, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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

Attachment Content-Type Size
dirtypages.sh application/x-sh 1.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-01-26 16:54:37 Re: WIP patch for parameterized inner paths
Previous Message Abhijit Menon-Sen 2012-01-26 16:45:39 Re: Should we add crc32 in libpgport?