Re: probably cause (and fix) for floating-point assist faults on itanium

Looks good to me. I built PG with this change, no kernel warnings after
~10 minutes of running. I'll continue to monitor but I think this fixes
the syndrome. Thanks Tom.

-Greg

On Fri, 18 Nov 2011, Tom Lane wrote:

> Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
>> On Thu, Nov 17, 2011 at 10:07 PM, Greg Matthews
>> <gregory(dot)a(dot)matthews(at)nasa(dot)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
>