Re: [PATCH v4 4/7] fs,x86/resctrl: Add architecture hooks for every mount/unmount

[Reinette Chatre]

Hi Tony,

On 4/23/26 3:29 PM, Luck, Tony wrote:
> On Wed, Apr 22, 2026 at 03:10:59PM -0700, Reinette Chatre wrote:
>> Hi Tony,
>>
>> On 4/22/26 2:59 PM, Luck, Tony wrote:
>>>>> Seems OK. But to make sure that events are accessible, architecture will
>>>>> now have to "hold" the pmt_telemetry module regardless of whether
>>>>> resctrl file system is mounted.
>>>>
>>>> Could you please elaborate why this is required? if I understand correctly the
>>>> "hold" on the pmt_telemetry module will be done by itself between the
>>>> intel_pmt_get_regions_by_feature() and intel_pmt_put_feature_group() calls.
>>>
>>> If architecture code runs completely asynchronously to resctrl mount/unmount
>>
>> Since there is shared state that is managed via existing locks I do not see
>> architecture running completely asynchronously to resctrl mount/unmount.
> 
> I think I now have a solution without any new locks in the file system
> layer (just a call to resctrl_arch_pre_mount() on every mount and a
> call to resctrl_arch_unmount() if the mount fails, and on unmount).
> 
> Testing in progress. Cleanup to follow before posting.

Thank you.

>>
>>> when would it be safe to call intel_pmt_put_feature_group()?
>>
>> I think I am missing something here since I have been assuming all along
>> that intel_pmt_put_feature_group() is and will continue to be called from the
>> new unmount handler.
> 
> Correct.
>>
>> Reinette
> 
> I'm looking at a more aggressive change to the Kconfig options.
> 
> Linus complained[1] that the biggest pain point for new people is getting
> the kernel configured. Extra CONFIG options was his prime focus.

Thank you for pointing this out.

> 
> So I'm looking at removing CONFIG_X86_CPU_RESCTRL_INTEL_AET completely and
> just making intel_aet.c included with CONFIG_X86_CPU_RESCTRL.

Sounds reasonable but how the final dependencies would look like is not obvious to me.
Consider for example this removal happening with today's Kconfig that may force
a kernel that will run on AMD/Hygon to be built with INTEL_PMT_TELEMETRY/INTEL_TPMI.
Something like this does not look right.

> It does mean the resctrl will depend on X86_64, killing 32-bit support.
> That was discussed before and decision deferred. But there's other 64-bit MMIO
> stuff in the pipeline that means we have to make this change sooner or later.
> 
> Thoughts on unconditional inclusion and on removing 32-bit support?

I believe we already have a clear answer on 32-bit support for resctrl on *x86*
from Thomas https://lore.kernel.org/lkml/87jzm3jckw.ffs@tglx/ and
Babu https://lore.kernel.org/lkml/162f5113-4eb6-dcea-f034-c81b9dc021b6@xxxxxxx/

Whether this can be extended to resctrl fs is not obvious to me but I think this
64-bit requirement is indeed limited to x86 here? 

About the unconditional inclusion I would just like to ensure that the
resulting dependencies are reasonable for all x86.

Reinette

> 
> -Tony
> 
> [1] https://lore.kernel.org/all/CAHk-=whigg3hvOy7c1j1MXFy6o6CHp0g4Tc3Y-MAk+XDssHU0A@xxxxxxxxxxxxxx