Re: [PATCH v11 06/10] fs/resctrl: Add user interface to enable/disable io_alloc feature

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

Hi Dave and Tony,

On 11/5/25 10:25 AM, Luck, Tony wrote:
>> But in AMD systems its the highest CLOSID (15). Also, this CLOSID usage 
>> in not visible to user. There is no update of PQR_ASSOC register during 
>> the context switch. Hardware internally routes the traffic using the 
>> CLOSID's(15) limits.
> 
> Things are even more complex for Intel IO as described in the RDT architecture
> specification. There can be separate IO caches from the CPU caches. When
> this happens the RMIDs and CLOSIDs for IO are in a separate space from
> those for CPU. I.e. you can assign RMID=1 CLOSID=1 to some tasks and
> those will measure and control traffic from a CPU L3 cache instance.
> IO devices may also use RMID=1, CLOSID=1 ... but those measure and
> control traffic from an IO cache instance.
> 
> This looks like the multi-socket case where RMID=1 on
> socket 0 (and thus L3 cache 0) is independent from RMID=1 on
> socket 1.  But resctrl partially hides this by making RMID allocation
> global and just providing separate event files for each L3 cache
> instance.
> 
> I don't think this maps to CPU vs IO. As Babu notes above, there's
> no update for IO CLOSID/RMID on process context switch. So it
> makes no sense to allocate IO RMIDs from the same pool as CPU
> RMIDs.
> 
> I haven't come up with any concrete plans for how to implement this
> version of IO RDT into resctrl. The earlier implementation on Granite Rapids
> didn't have IO caches independent from CPU caches.

It seems to common now that we need to build support for new features and ideally
any new interface can be designed with some gateway to enable future enhancements. SDCIAE/io_alloc
is a global IO alloc feature while the ones mentioned here for Arm and Intel seem to be a better
match to be managed per resource group. I did try to think how to "keep the door open" for
future enhancements, hypothetically "/sys/fs/resctrl/info/L3/io_alloc" could in the future
return a new value that implies "managed_in_resource_group" that opens door to create
new interfaces in the resource groups to manage IO alloc there. The "io_alloc" documentation
does seem high level enough to support such an enhancement.

Do you see any additional changes we can add to the interface or documentation to
set resctrl up for success to support these features in the future?

Reinette