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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1809272209160.8118@nanos.tec.linutronix.de>
Date:   Thu, 27 Sep 2018 22:14:16 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Moger, Babu" <Babu.Moger@....com>
cc:     "mingo@...hat.com" <mingo@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "reinette.chatre@...el.com" <reinette.chatre@...el.com>,
        "vikas.shivappa@...ux.intel.com" <vikas.shivappa@...ux.intel.com>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "pombredanne@...b.com" <pombredanne@...b.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "kstewart@...uxfoundation.org" <kstewart@...uxfoundation.org>,
        "bp@...e.de" <bp@...e.de>,
        "rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
        "ak@...ux.intel.com" <ak@...ux.intel.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "xiaochen.shen@...el.com" <xiaochen.shen@...el.com>,
        "colin.king@...onical.com" <colin.king@...onical.com>,
        "Hurwitz, Sherry" <sherry.hurwitz@....com>,
        "Lendacky, Thomas" <Thomas.Lendacky@....com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "dwmw@...zon.co.uk" <dwmw@...zon.co.uk>,
        "luto@...nel.org" <luto@...nel.org>,
        "jroedel@...e.de" <jroedel@...e.de>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "dima@...sta.com" <dima@...sta.com>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        James Morse <james.morse@....com>
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@arm.com

Thanks,

	tglx