On 01-Nov-19 11:00 PM, Thomas Monjalon wrote:
29/10/2019 15:05, Hunt, David:
On 27/10/2019 18:35, Thomas Monjalon wrote:
06/08/2019 13:18, Thomas Monjalon:
26/07/2019 12:15, Burakov, Anatoly:
So it's biased towards scaling up quickly, but it's doing that over a
period. Please correct me if i'm wrong as i'm not really familiar with
this codebase, but, assuming the window size is long enough, you could
be missing opportunities to scale down? For example, if you get a short
burst of 1's followed by a long burst of zeroes, you're not scaling down
until you go through the entire buffer and overwrite all of the values.
I guess that's the point of oscillation prevention, but maybe you could
improve the "scale-up" part by only checking a few recent values, rather
than the entire buffer?
This patch is deferred to 19.11.
Any news for this patch?
The algorithm was intended to be biased (strongly) towards the scale-up,
for performance reasons. If there is a single "scale-up" in the entire
array, then we stay up until the entire array agrees that we can scale
down. If the user wants to relax this, then simply reduce the size of
the array, which will have the same affect. But I had tested it with an
array size of 32, and that gave the best results for my use cases.
I'm not sure to understand. The patch is rejected?
I believe he was responding to my question about the algorithm's bias.
Now that the matter is resolved,
Acked-by: Anatoly Burakov <anatoly.bura...@intel.com>
--
Thanks,
Anatoly
