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

[Ben Horgan]

Hi Reinette,

On 7/16/26 18:50, Reinette Chatre wrote:
> 
> Hi Tony and Ben,
> 
> On 7/16/26 9:22 AM, Ben Horgan wrote:
>> Hi Tony,
>>
>> On 7/16/26 17:02, Luck, Tony wrote:
>>>>> This was one element of original discussion that fizzled a bit since it was not obvious that user
>>>>> space would behave like this. Consider, for example, from Documentation/filesystems/resctrl.rst:
>>>>>
>>>>>     Reading/writing the schemata file
>>>>>     ---------------------------------
>>>>>     ... When writing you only need to specify those values which you wish to change. ..
>>>>
>>>> Yeah, I don't know but it does seem like something a user could reasonably expect to work.
>>>
>>> Personally I use one of two options to update schemata:
>>>
>>> 1) Just want to change something small:
>>> 	# echo "MB:1=50" > schemata
>>> 2) I want to make global change to some resource
>>> 	# vi schemata
>>> 		on L2 line: s/ffff/ff/g
>>> 	:wq
>>>
>>> In case 2 every domain on every resource is written, but most of them to the existing value.
>>
>> We've got a user :)
>>
>>>
>>> This may need careful consideration if the legacy "MB" lines are present together with the
>>> new controls for MIN, MAX etc.
>>>
>>> Having a mode file to select whether legacy OR native controls are exposed would avoid
>>> a lot of complexity in the kernel. Yes, that would mean a user that wants to use the new
>>> native interface must add one "echo" to some startup script.
>>>
>>> Or perhaps yet another "rdt=" command line option to pick whether mount defaults to
>>> legacy or native mode?
>>
>> The "rdt=" options are x86 specific so I don't think we should use them for generic resctrl. A mount
>> option might be end up being convenient.
> What is the recommended way for users to discover which mount options are supported
> by a filesystem? I am not familiar with this area and a quick search showed that this could
> be supported if user space programmatically splits the mount into distinct steps to first
> discover if the filesystem's parser accepts the mount parameter before attempting to
> mount the filesystem. It sounds to me as though a mount parameter would place additional
> burden on user space?

My thought here was that it could just be an easy way for the user to say they wanted to default to
the native interface for all controls and that it would have no effect if there were no possible
native controls. We would have to be careful to only introduce any command line or mount option once
we have support for everything it can effect so its meaning doesn't change over time.

(I'm also not really familiar with mount option usage which is why I have just talked tangentially
to your question.)

Thanks,

Ben

> 
> I am also concerned about how resctrl could confidently build on top of such mount option.
> Would resctrl need to add new mount options to build on top of the ones introduced in the
> base or would resctrl need to create two different filesystems? Both sounds like a challenge
> to me.
> 
> Reinette