On 04.01.2012 07:58, Peter Geoghegan wrote:
As part of the ongoing effort to reduce wake-ups when idle/power
consumption, the attached patch modifies the background writer to
hibernate in ten second bursts once the bgwriter laps the clock sweep.
It's fairly well commented, so a description of how it works here
would probably be redundant. The most controversial aspect of this
patch is the fact that it adds a SetLatch() call to MarkBufferDirty(),
though I went to some lengths to ensure that that call will very
probably find the latch already set when it actually matters, so it
only checks a single flag.
I think SetBufferCommitInfoNeedsSave() needs the same treatment as
MarkBufferDirty(). And it would probably be good to only set the latch
if the buffer wasn't dirty already. Setting a latch that's already set
is fast, but surely it's even faster to not even try.
Thoughts? I can produce benchmarks, if that helps, but I think it's
fairly unlikely that the patch introduces a measurable performance
regression.
Yeah, I'd like to see a micro-benchmark of a worst-case scenario. I'm a
bit worried about the impact on systems with a lot of CPUs. If you have
a lot of CPUs writing to the same cache line that contains the latch's
flag, that might get expensive.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 10 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJan 4, '12 at 5:58a
activeJan 27, '12 at 7:17a
posts10
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase