Re: [PATCH v5 0/3] x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch

[Ben Horgan <ben.horgan@arm.com>]

Hi Reinette,

On 08/09/2026 16:35, Reinette Chatre wrote:
> Hi Ben,
> 
> On 9/7/26 3:44 AM, Ben Horgan wrote:
>> Hi Boris, Reinette,
>>
>> On 04/09/2026 18:36, Borislav Petkov wrote:
>>> On Thu, Sep 03, 2026 at 08:37:51PM -0700, Borislav Petkov wrote:
>>>> Lemme have a look.
>>>
>>> Sashiko has comments:
>>>
>>> https://sashiko.dev/#/patchset/20260709093111.367851-1-ben.horgan%40arm.com
>>>
>>> Please address them: if valid, fix them, if not, explain why they don't need
>>> to be fixed.
>>>
>>> Thx.
>>>
>>
>> Regarding the first Sashiko comment.
>>
>> The documentation change in patch 3 includes the sentence:
>>
>> "
>> The allocated bandwidth percentage is rounded up to the next control step available on the
>> hardware.
>> "
>>
>> Sashiko rightly objects to the "rounded up". For MPAM systems this can be up or down and we test in
>> test_mpam_resctrl.c:test_percent_to_max_rounding() that it isn't too biased to rounding one way or
>> the other.
>>
>> How about replacing "rounded up" with "rounded up or down" so that the sentence becomes:
>>
>> "
>> The allocated bandwidth percentage is rounded up or down to the next control step available on the
>> hardware.
>> "
>>
>> What do you think? Should I respin the series with this alteration?
> The change looks good to me since Intel always rounds up. By itself "rounded" may thus be deceiving.
> One concern is that "next" seems to accompany "round up" to reflect forward/upward movement.
> How about also replacing "next" with "nearest" or "closest"?

Ok, I'll go with "closest".

> 
> I think a respin would be most convenient to ensure the intended changes are made.

Will do.

Thanks,

Ben

> 
> Reinette