Re: [PATCH v7 00/49] x86/resctrl: Move the resctrl filesystem code to /fs/resctrl

Moger, Babu
2025-03-05T20:48:03Z

On 3/5/25 10:35, Reinette Chatre wrote:
>
>
> On 3/4/25 1:47 PM, Luck, Tony wrote:
>> On Fri, Feb 28, 2025 at 07:58:24PM +0000, James Morse wrote:
>>> Changes since v6?:
>>> * All the excitement is in patch 37, turns out there are two rmdir() paths
>>> that don't join up.
>>> The last eight patches are new:
>>> * The python script has been replaced with the patch that it generates, see
>>> the bare branch below if you want to regenerate it.
>>> * There have been comments on the followup to the generated patch, those are
>>> included here - I suggest they be squashed into the generated patch.
>>> * This version includes some checkpatch linting from Dave.
>>>
>>> ---
>>> This series renames functions and moves code around. With the
>>> exception of invalid configurations for the configurable-events, there should
>>> be no changes in behaviour caused by this series. It is now possible for
>>> throttle_mode to report 'undefined', but no known platform will do this.
>>>
>>> The driving pattern is to make things like struct rdtgroup private to resctrl.
>>> Features like pseudo-lock aren't going to work on arm64, the ability to disable
>>> it at compile time is added.
>>>
>>> After this, I can start posting the MPAM driver to make use of resctrl on arm64.
>>> (What's MPAM? See the cover letter of the first series. [1])
>>>
>>> This series is based on v6.14-rc3 and can be retrieved from:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v7
>>> or for those who want to regnerate the patch that moves all the code:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/move_to_fs/v7_bare
>>>
>>>
>>> As ever - bugs welcome,
>>> Thanks,
>>>
>>> James
>>
>> Upstream is at -rc5, so it's time to pick what to ask Boris to
>> apply to tip for the upcoming v6.15 merge window.
>>
>> There are several open issues for Babu's ABMC series. So it
>> isn't ready at this time.

I agree. ABMC series is not ready yet.

This series should merge first. I have tested on couple of AMD systems
and everything looks good. I will respond with Tested-by and reviewed-by.

>>
>> Also several against this MPAM series from James ... but IMHO the
>> first bunch of patches look to be in good shape with a
>> full set of Reviewed-by and Tested-by tags on parts 1-7,9-11,13-17
>> (things get murkier in the 20's and maybe more likely to have
>> issues due to skipping patches that don't have all their tags).
>>
>> So I applied those patches on top of v6.14-rc5 (all but one applied
>> automatically, patch 10 had two line "fuzz" due to skipping patch 8).
>>
>> Resulting kernel builds (with W=1), boots, and passes the tests
>> in tools/tests/selftests/resctrl.
>>
>> In the interests of making forward progress, should we ask Boris
>> to take this subset of the MPAM series?
>>
>
> Sounds like there may have only been about a five minute window for
> clarifying questions about v6 before the door was shut on it.
> Since I missed that window by a couple of hours I'll move to
> v7 where the MPAM pressure has so promptly shifted.
>
> I'd be happy to work with Boris and other x86 maintainers on
> any mechanism they prefer.
>

Sure. Please go ahead.
--
Thanks
Babu Moger