Re: [PATCH] Change min/max to float numbers

[Rafael Folco <rfolco@redhat.com>]

On 06/02/25 12:09, Sebastian Andrzej Siewior wrote:
> On 2025-02-06 12:02:49 [-0300], Rafael Folco wrote:
>> On 06/02/25 09:00, Sebastian Andrzej Siewior wrote:
>>> On 2025-02-06 06:16:22 [-0300], Rafael Folco wrote:
>>>> Make min/max consistent with avg by recording the latency samples
>>>> as float numbers instead of integers.
>>>
>>> Why?
>>
>> - More precise numbers of Max/Min for extreme low latency cases
>> - Distinguish zero latency in bucket 001 (us)
>> - Distinguish values from upper/lower boundaries in a bucket
>> - Clarify confusion on average (round up) vs maximum in the next bucket (casting)
>>
>> Instead of:
>>         Core:    3 4 5
>> Counter Freq:    2100 2100 2100 (MHz)
>>     001 (us):    14880514 14880447 14880442
>>     002 (us):    0 0 0
>>     003 (us):    0 0 0
>>     004 (us):    0 0 0
>>     005 (us):    0 0 0 (including overflows)
>>      Minimum:    0 0 0 (us)
>>      Average:    1.000 1.000 1.000 (us)
>>      Maximum:    0 0 0 (us)
>>      Max-Min:    0 0 0 (us)
>>
>> We'd see:
>>         Core:    3 4 5
>> Counter Freq:    2100 2100 2100 (MHz)
>>     001 (us):    12578842 12491108 12578752
>>     002 (us):    0 0 0
>>     003 (us):    0 0 0
>>     004 (us):    0 0 0
>>     005 (us):    0 0 0 (including overflows)
>>      Minimum:    0.033 0.035 0.035 (us)
>>      Average:    1.000 1.000 1.000 (us)
>>      Maximum:    0.129 0.153 0.134 (us)
>>      Max-Min:    0.095 0.118 0.099 (us)
> 
> so core 3 has min 33ns and max 129ns while 1us on average?
Yes, because avg rounds up.
There are some other potential fixes coming like:
- stop rounding up avg
- splitting bucket 001 (us) which is bigger (0 - 1.99999)
- adding the max bucket to the end (do not limit to 32us)

... but these are out of scope for this change. 

Folco
> 
> Sebastian
>