Re: [RFC PATCH 00/10] arch/x86: AMD QoS support

[James Morse]

Hi Babu,

(Thanks for looping me in!)

On 28/09/18 02:57, Moger, Babu wrote:
>> On Mon, 24 Sep 2018, Moger, Babu wrote:
>>
>>> This series adds support for AMD64 architectural extensions for Platform
>>> Quality of Service. These extensions are intended to provide for the
>>> monitoring of the usage of certain system resources by one or more
>>> processors and for the separate allocation and enforcement of limits on
>>> the use of certain system resources by one or more processors.
>>>
>>> The monitoring and enforcement are not necessarily applied across the
>>> entire system, but in general apply to a QOS domain which corresponds to
>>> some shared system resource.  The set of resources which are monitored
>> and
>>> the set for which the enforcement of limits is provided are implementation
>>> dependent. Platform QOS features are implemented on a logical processor
>> basis.
>>> Therefore, multiple hardware threads of a single physical CPU core may
>> have
>>> independent resource monitoring and enforcement configurations.
>>>
>>> AMD's next generation of processors support following QoS sub-features.
>>> - L3 Cache allocation enforcement
>>> - L3 Cache occupancy monitoring
>>> - L3 Code-Data Prioritization support
>>> - Memory Bandwidth Enforcement(Allocation)
>>>
>>> The public specification is still in works. Will add the link when it is
>>> available.
>>>
>>> Obviously, there are multiple ways we can go about these changes. We felt
>>> it is appropriate to rename and re-organize the code little bit before
>>> making the functional changes. The first few patches(1-6) renames and
>>> re-organizes the sources in preparation. Rest of the patches(7-10) adds
>>> support for AMD QoS features.
>>
>> On the first glance this all looks sensible, but there is work in progress
>> by James Morse (Cc'ed), who wants to generalize the resctrl filesystem so
>> it can be reused by ARM. I just want to make sure that your reorganization
>> is not colliding or creating duplicate effort.

Aha, some of this makes my life easier. I'm against having the ABI different
between architectures. This meant contiguous bitmaps on arm, which the MPAM
stuff doesn't actually require...


> Thanks for pointing this out. I have looked thru James patches. It appears this
> series is only a small part of his much bigger change. Don't know the timeframe
> of his overall changes.
> I will let him speak on that.

Longer, as its more invasive,


> That being said, I don't consider our efforts as
> duplicate. He is touching the resource structures, and trying to separate arch,
> non-arch components.
> My changes are mostly inside the resource structures(mostly resource handlers)

> and trying to accommodate minor differences within the architecture.  It will
> be mostly involve rebase
> effort on either side in the end whoever goes first.

> James, What are your thoughts? 

I think your stuff should go first. It doesn't look like you are adding new
features/controls, so its normally:painful for me to rebase over it.
(doing it the other-way round would be harder!)


Thanks,

James