From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Greg Matthews <gregory.a.matthews@nasa.gov>
Cc: pgsql-performance@postgresql.org
Subject: Re: probably cause (and fix) for floating-point assist faults on itanium
Date: Fri, 18 Nov 2011 11:11:41 -0500
Message-ID: <18092.1321632701@sss.pgh.pa.us> (raw)
In-Reply-To: <CAGTBQpYjs8GHBk1mf__dYVH=4g7ZK2jHrN7ubNYJtYX+47OzNg@mail.gmail.com>
References: <Pine.LNX.4.64.1111171643570.10000@linux105.nas.nasa.gov>
<CAGTBQpYjs8GHBk1mf__dYVH=4g7ZK2jHrN7ubNYJtYX+47OzNg@mail.gmail.com>
Claudio Freire <klaussfreire@gmail.com> writes:
> On Thu, Nov 17, 2011 at 10:07 PM, Greg Matthews
> <gregory.a.matthews@nasa.gov> wrote:
>> if (smoothed_alloc <= (float) recent_alloc)
>> smoothed_alloc = recent_alloc;
>> else if (smoothed_alloc >= 0.00001)
>> smoothed_alloc += ((float) recent_alloc - smoothed_alloc) /
>> smoothing_samples;
>>
> I don't think that logic is sound.
> Rather,
> if (smoothed_alloc <= (float) recent_alloc) {
> smoothed_alloc = recent_alloc;
> } else {
> if (smoothed_alloc < 0.000001)
> smoothed_alloc = 0;
> smoothed_alloc += ((float) recent_alloc - smoothed_alloc) /
> smoothing_samples;
> }
The real problem with either of these is the cutoff number is totally
arbitrary. I'm thinking of something like this:
/*
* Track a moving average of recent buffer allocations. Here, rather than
* a true average we want a fast-attack, slow-decline behavior: we
* immediately follow any increase.
*/
if (smoothed_alloc <= (float) recent_alloc)
smoothed_alloc = recent_alloc;
else
smoothed_alloc += ((float) recent_alloc - smoothed_alloc) /
smoothing_samples;
/* Scale the estimate by a GUC to allow more aggressive tuning. */
upcoming_alloc_est = smoothed_alloc * bgwriter_lru_multiplier;
+ /*
+ * If recent_alloc remains at zero for many cycles,
+ * smoothed_alloc will eventually underflow to zero, and the
+ * underflows produce annoying kernel warnings on some platforms.
+ * Once upcoming_alloc_est has gone to zero, there's no point in
+ * tracking smaller and smaller values of smoothed_alloc, so just
+ * reset it to exactly zero to avoid this syndrome.
+ */
+ if (upcoming_alloc_est == 0)
+ smoothed_alloc = 0;
/*
* Even in cases where there's been little or no buffer allocation
* activity, we want to make a small amount of progress through the buffer
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, klaussfreire@gmail.com, gregory.a.matthews@nasa.gov
Subject: Re: probably cause (and fix) for floating-point assist faults on itanium
In-Reply-To: <18092.1321632701@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox