Thread (17 messages) 17 messages, 5 authors, 20d ago

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

From: Ben Horgan <ben.horgan@arm.com>
Date: 2026-09-08 15:45:07
Also in: linux-doc, lkml

Hi Reinette,

On 08/09/2026 16:35, Reinette Chatre wrote:
Hi Ben,

On 9/7/26 3:44 AM, Ben Horgan wrote:
quoted
Hi Boris, Reinette,

On 04/09/2026 18:36, Borislav Petkov wrote:
quoted
On Thu, Sep 03, 2026 at 08:37:51PM -0700, Borislav Petkov wrote:
quoted
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
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help