Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept

[Reinette Chatre <reinette.chatre@intel.com>]

Hi Ben,

On 7/22/26 3:03 AM, Ben Horgan wrote:
> On 7/21/26 18:30, Reinette Chatre wrote:
>> On 7/21/26 6:23 AM, Ben Horgan wrote:
>>> On 7/20/26 23:54, Reinette Chatre wrote:

...
>>> I don't think we should introduce more percent based controls and for new controls we can introduce
>>> a new format to describe them. Perhaps just the positive integer with a resolution supplied in info/
>>
>> No, we should not introduce more percentage based controls per se. With the new schema format a
>> percentage based control is just a variant of a proportional scalar control.
>>
>>> as discussed previously. Although, I have been pondering on whether we can do a bit better.
>>>
>>> We could use hexadecimal point based format for controls which are a proportion of a resource and
>>> have a resolution which is a power of 2. The advantage of this is that the meaning of the value is
>>> independent of the granularity of the control (number of parts).
>>>
>>> 0 is represented as 0x0
>>> 1 as                0x1
>>> 1/2 as              0x0.8
>>> 7/256 as            0x0.07
>>> 1/2**28             0x0.00000001
>>> etc
>>>
>>> This maps well to the MPAM fixed-point fraction point format without having the weirdness of having
>>> values forced to 1 or 0 not being really 0. These MPAM h/w oddities can be hidden just by using the
>>> mbw_min mbw_max of a control. In MPAM this could be used in CMIN, CMAX, MB_MAX, MB_MIN and I would
>>> hope this would be useful for other architectures too. I am preparing some RFC patches on top of
>>> your PoC for consideration of this idea and to explore some of the proposals discussed relating to
>>> generic schemata and how they land in practice from the MPAM side.
>>
>> I'm going to stand with Dave Martin [1] on this point with a preference to avoid floating point in
>> resctrl input and output.
> 
> Ok, but I'm not suggesting floating point. Dave's two objections to floating point were that it's
> not exact and that it's hard to parse. For the first it is exact as it is using base 16 and for the
> parsing it's essentially parsing a prefix, '0x0.', and then a hexadecimal value and shifting for
> resolution. 0 and 1 will need to be considered as special cases. What I did wonder if it was too
> weird a format for userspace. Anyhow, no point flogging a dead horse, let's just go with using a
> number in a proportional schema along with the resolution as Dave summarized in [1]
> 
> [1] https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/

ok. I do like how the scalar control from that proposal accommodates a variety of proportional and
absolute hardware controls without forcing/requiring hardware controls to be a particular shape.

> 
>> Could you please elaborate where values are forced to 1 or 0? The new schema format was intentionally
>> created to *avoid* rounding errors (and parsing complexity).
> 
> This a property of the MPAM fixed-point fraction point format in the hardware. It would need to be
> hidden whatever resctrl schema format is used, percentage, scalar, fraction ... etc.

Just a clarification, all three of the examples you mention (percentage, scalar, fraction) are currently
expected to be supported by the single "scalar" control.

(see later for comment on "need to be hidden")

> For an MPAM MBW MAX control with a width of 4 bit the range of values in 0-0xF. In this set up the
> resolution is 16 but there are only 15 possible values. For MBW MAX a 0 in hardware the minimum
> value which becomes 1/16, ~6%.
> See mpam_resctrl.c:mbw_max_to_percent() for how this is currently dealt with.
> 
> For an MPAM MBW MIN control we shift the other way and so 0 is 0 but (with 4 bits) 0xF is 15/16 ~94%.
> When the input resolution is a power of 2 these conversions between h/w value and schemata value can
> be slightly simplified but there is still some ugly offset of 1.
> 
> (The spec is a little less precise than this and uses weasel words like "Arm recommends..." but this
> seems to be the sensible interpretation. See ARM IHI0099B.c "MPAM system component specification",
> Section 9.3.)

Thank you for the clarification. Sounds related to the weasel words in
https://lore.kernel.org/lkml/20260709093111.367851-4-ben.horgan@arm.com/ that took us a while to settle on.

You mention above that this would need to be hidden but from what I understand this is accommodated by
the "tolerance" property of the "scalar" control?

Per https://lore.kernel.org/lkml/aPtfMFfLV1l%2FRB0L@e133380.arm.com/:

	Note on the "tolerance" parameter:

	This is a new addition.  On the MPAM side, the hardware has a choice
	about how to interpret the control value in some edge-case situations.
	We may not reasonably be able to probe for this, so it may be useful
	to warn software that there is an uncertainty margin.


>> [1] https://lore.kernel.org/lkml/aNFliMZTTUiXyZzd@e133380.arm.com/
>>
>>>> I also understand MPAM to support more memory bandwidth controls ("MIN", "HARDMAX"/"HARDLIM", etc.).
>>>> Do you envision them to exist within info/MB/resource_schemata/<control> as well as within
>>>> info/MB_NODE/resource_schemata/<control>?
>>>
>>> Yes, at least for MIN, see the info/ tree above. For HARDLIM, perhaps, but HARDLIM has the added
>>> complications that it is a property of the MBW_MAX control and that it may be configurable for each
>>> PARTID or a fixed property of the h/w. When HARDLIM is configurable the control name could be of the
>>> form <resource_type>_<scope>_<control>_<control_param> where <control_param> is HARDLIM and the full
>>> name for the HARDLIM configuration on the MB_NODE resource is MB_NODE_MAX_HARDLIM. There can also be
>>> an info/<resource>/resource_schemata/<control>/lim file which has values, soft, hard, configurable.
>>
>> ack. HARDLIM sounds like it would be a new control type. Perhaps a "boolean" type for which new control
>> files need to be decided on? Sounds like you are headed in this direction and already have one control file
>> in mind for this new type.
>>
>> With this in mind the control could be built on top of what is being developed at the moment, possibly
>> be presented to user space following Dave Martin's suggestion in
>> https://lore.kernel.org/lkml/aO0Oazuxt54hQFbx@e133380.arm.com/:
>>
>>  | MB_HARDMAX: 0=0, 1=1, 2=1, 3=0 [...]
>>
>>  or
>>
>>  | MB_HARDMAX: 0=off, 1=on, 2=on, 3=off [...]
> 
> I'm happy with either of these format but have a slight preference for the second as on/off more
> clearly indicates this is a boolean with only two choices.

So far I am only aware of MPAM needing a boolean control which hints to me that MPAM can set direction here.

Reinette