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

[Moger, Babu]

Thomas, 

> -----Original Message-----
> From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Sent: Thursday, September 27, 2018 3:14 PM
> To: Moger, Babu <Babu.Moger@xxxxxxx>
> Cc: mingo@xxxxxxxxxx; hpa@xxxxxxxxx; fenghua.yu@xxxxxxxxx;
> reinette.chatre@xxxxxxxxx; vikas.shivappa@xxxxxxxxxxxxxxx;
> tony.luck@xxxxxxxxx; x86@xxxxxxxxxx; peterz@xxxxxxxxxxxxx;
> pombredanne@xxxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx;
> kstewart@xxxxxxxxxxxxxxxxxxx; bp@xxxxxxx; rafael.j.wysocki@xxxxxxxxx;
> ak@xxxxxxxxxxxxxxx; kirill.shutemov@xxxxxxxxxxxxxxx;
> xiaochen.shen@xxxxxxxxx; colin.king@xxxxxxxxxxxxx; Hurwitz, Sherry
> <sherry.hurwitz@xxxxxxx>; Lendacky, Thomas
> <Thomas.Lendacky@xxxxxxx>; pbonzini@xxxxxxxxxx;
> dwmw@xxxxxxxxxxxx; luto@xxxxxxxxxx; jroedel@xxxxxxx;
> jannh@xxxxxxxxxx; dima@xxxxxxxxxx; jpoimboe@xxxxxxxxxx;
> vkuznets@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; James Morse
> <james.morse@xxxxxxx>
> Subject: Re: [RFC PATCH 00/10] arch/x86: AMD QoS support
> 
> Babu,
> 
> 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.
> 
> https://lkml.kernel.org/r/20180824104519.11203-1-james.morse@xxxxxxx

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.  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? 

> 
> Thanks,
> 
> 	tglx