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

[James Morse]

Hi Peter,

On 03/03/2025 10:14, Peter Newman wrote:
> On Fri, Feb 28, 2025 at 8:59 PM James Morse <james.morse@xxxxxxx> 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

> I applied the series successfully and ran through my usual assortment
> of container management-oriented testcases on the following
> implementations:

> * AMD EPYC 7B12 64-Core Processor

Great! This is something I've not managed to get my hands on.


> * Intel(R) Xeon(R) Gold 6268CL CPU @ 2.80GHz
> 
> Everything looked good.
> 
> Tested-by: Peter Newman <peternewman@xxxxxxxxxx>

Thanks!

James