On 17.01.2012 14:38, Peter Geoghegan wrote:
On 17 January 2012 11:24, Heikki Linnakangas <heikki.linnakan...@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
dirtypages.sh
Description: Bourne shell script
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
