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@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
>