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

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

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?

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