[dpdk-dev] [PATCH v1] examples/power: fix oob frequency oscillations

Burakov, Anatoly anatoly.burakov at intel.com
Mon Nov 4 11:16:42 CET 2019


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.burakov at intel.com>

-- 
Thanks,
Anatoly


More information about the dev mailing list