Hi James, On 10/05/2018 11:18 AM, James Morse wrote: > 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,
Ok. Thanks for the heads up. > > >> 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!) Ok. Sounds good. I will send v2 version soon. Feel free to review. > > > Thanks, > > James >
