To: Claudio Freire <klaussfreire@gmail.com>
cc: Greg Matthews <gregory.a.matthews@nasa.gov>,
	pgsql-performance@postgresql.org
Subject: Re: probably cause (and fix) for floating-point assist faults on
	itanium
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>
Comments: In-reply-to Claudio Freire <klaussfreire@gmail.com>
	message dated "Fri, 18 Nov 2011 11:21:52 -0300"
Date: Fri, 18 Nov 2011 11:11:41 -0500
Message-ID: <18092.1321632701@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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