Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Moger, Babu" <Babu.Moger@amd.com>
To:     Thomas Gleixner <tglx@linutronix.de>,
        James Morse <james.morse@arm.com>
CC:     "mingo@redhat.com" <mingo@redhat.com>,
        "hpa@zytor.com" <hpa@zytor.com>,
        "fenghua.yu@intel.com" <fenghua.yu@intel.com>,
        "reinette.chatre@intel.com" <reinette.chatre@intel.com>,
        "vikas.shivappa@linux.intel.com" <vikas.shivappa@linux.intel.com>,
        "tony.luck@intel.com" <tony.luck@intel.com>,
        "x86@kernel.org" <x86@kernel.org>,
        "peterz@infradead.org" <peterz@infradead.org>,
        "pombredanne@nexb.com" <pombredanne@nexb.com>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "kstewart@linuxfoundation.org" <kstewart@linuxfoundation.org>,
        "bp@suse.de" <bp@suse.de>,
        "rafael.j.wysocki@intel.com" <rafael.j.wysocki@intel.com>,
        "ak@linux.intel.com" <ak@linux.intel.com>,
        "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>,
        "xiaochen.shen@intel.com" <xiaochen.shen@intel.com>,
        "colin.king@canonical.com" <colin.king@canonical.com>,
        "Hurwitz, Sherry" <sherry.hurwitz@amd.com>,
        "Lendacky, Thomas" <Thomas.Lendacky@amd.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "dwmw@amazon.co.uk" <dwmw@amazon.co.uk>,
        "luto@kernel.org" <luto@kernel.org>,
        "jroedel@suse.de" <jroedel@suse.de>,
        "jannh@google.com" <jannh@google.com>,
        "dima@arista.com" <dima@arista.com>,
        "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
        "vkuznets@redhat.com" <vkuznets@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC PATCH 00/10] arch/x86: AMD QoS support
Thread-Topic: [RFC PATCH 00/10] arch/x86: AMD QoS support
Thread-Index: AQHUVDtunpE+5D/HD063flof44uaLaUElN0AgABe+SA=
Date:   Fri, 28 Sep 2018 01:57:38 +0000
Message-ID: <DM5PR12MB24719940B13119E05738DB3495EC0@DM5PR12MB2471.namprd12.prod.outlook.com>
References: <20180924191841.29111-1-babu.moger@amd.com>
 <alpine.DEB.2.21.1809272209160.8118@nanos.tec.linutronix.de>
In-Reply-To: <alpine.DEB.2.21.1809272209160.8118@nanos.tec.linutronix.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ee6cd22b-e645-44eb-dfdf-08d624e5c4c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2018 01:57:38.5403
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1675
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Thomas,=20

> -----Original Message-----
> From: Thomas Gleixner <tglx@linutronix.de>
> Sent: Thursday, September 27, 2018 3:14 PM
> To: Moger, Babu <Babu.Moger@amd.com>
> Cc: mingo@redhat.com; hpa@zytor.com; fenghua.yu@intel.com;
> reinette.chatre@intel.com; vikas.shivappa@linux.intel.com;
> tony.luck@intel.com; x86@kernel.org; peterz@infradead.org;
> pombredanne@nexb.com; gregkh@linuxfoundation.org;
> kstewart@linuxfoundation.org; bp@suse.de; rafael.j.wysocki@intel.com;
> ak@linux.intel.com; kirill.shutemov@linux.intel.com;
> xiaochen.shen@intel.com; colin.king@canonical.com; Hurwitz, Sherry
> <sherry.hurwitz@amd.com>; Lendacky, Thomas
> <Thomas.Lendacky@amd.com>; pbonzini@redhat.com;
> dwmw@amazon.co.uk; luto@kernel.org; jroedel@suse.de;
> jannh@google.com; dima@arista.com; jpoimboe@redhat.com;
> vkuznets@redhat.com; linux-kernel@vger.kernel.org; James Morse
> <james.morse@arm.com>
> Subject: Re: [RFC PATCH 00/10] arch/x86: AMD QoS support
>=20
> Babu,
>=20
> On Mon, 24 Sep 2018, Moger, Babu wrote:
>=20
> > This series adds support for AMD64 architectural extensions for Platfor=
m
> > 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 t=
o
> > some shared system resource.  The set of resources which are monitored
> and
> > the set for which the enforcement of limits is provided are implementat=
ion
> > 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 i=
s
> > available.
> >
> > Obviously, there are multiple ways we can go about these changes. We fe=
lt
> > 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.
>=20
> On the first glance this all looks sensible, but there is work in progres=
s
> 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 reorganizatio=
n
> is not colliding or creating duplicate effort.
>=20
> https://lkml.kernel.org/r/20180824104519.11203-1-james.morse@arm.com

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 effort=
s as duplicate. He is touching the resource structures, and trying to separ=
ate arch, non-arch components.
My changes are mostly inside the resource structures(mostly resource handle=
rs) and trying to accommodate minor differences within the architecture.  I=
t will be mostly involve rebase
effort on either side in the end whoever goes first.

James, What are your thoughts?=20

>=20
> Thanks,
>=20
> 	tglx