[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180824104519.11203-1-james.morse@arm.com>
Date: Fri, 24 Aug 2018 11:44:59 +0100
From: James Morse <james.morse@....com>
To: linux-kernel@...r.kernel.org
Cc: x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
Fenghua Yu <fenghua.yu@...el.com>,
Tony Luck <tony.luck@...el.com>,
Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
Reinette Chatre <reinette.chatre@...el.com>,
Vikas Shivappa <vikas.shivappa@...ux.intel.com>
Subject: [RFC PATCH 00/20] x86/intel_rdt: Start abstraction for a second arch
Hi folks,
ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl
is the defacto ABI for this sort of thing, but it lives under arch/x86.
To get existing software working, we need to make resctrl work with arm64.
This series is the first chunk of that. The aim is to move the filesystem/ABI
parts into /fs/resctrl, and implement a second arch backend.
What are the ARM features?
Future ARM SoCs may have a feature called MPAM: Memory Partitioning and
Monitoring. This is an umbrella term like RDT, and covers a range of controls
(like CAT) and monitors (like MBM, CMT).
This series is almost all about CDP. MPAM has equivalent functionality, but
it doesn't need enabling, and doesn't affect the available closids. (I'll
try and use Intel terms). MPAM expects the equivalent to IA32_PRQ_MSR to
be configured with an Instruction closid and a Data closid. These are the
same for no-CDP, and different otherwise. There is no need for them to be
adjacent.
To avoid emulating CDP in arm64's arch code, this series moves all the ABI
parts of the CDP behaviour, (half the closid-space, each having two
configurations) into the filesystem parts of resctrl. These will eventually
be moved to /fs/.
MPAMs control and monitor configuration is all memory mapped, the base
addresses are discovered via firmware tables, so we won't have a table of
possible resources that just need alloc_enabling.
Is this it? No... there are another two series of a similar size that
abstract the MBM/CMT overflow threads and avoid 'fs' code accessing things
that have moved into the 'hw' arch specific struct.
I'm after feedback on the general approach taken here, bugs, as there are
certainly subtleties I've missed, and any strong-opinions on what should be
arch-specific, and what shouldn't.
This series is based on v4.18, and can be retrieved from:
git://linux-arm.org/linux-jm.git -b mpam/resctrl_rework/rfc_1
Thanks,
James Morse (20):
x86/intel_rdt: Split struct rdt_resource
x86/intel_rdt: Split struct rdt_domain
x86/intel_rdt: Group staged configuration into a separate struct
x86/intel_rdt: Add closid to the staged config
x86/intel_rdt: make update_domains() learn the affected closids
x86/intel_rdt: Add a helper to read a closid's configuration for
show_doms()
x86/intel_rdt: Expose update_domains() as an arch helper
x86/intel_rdt: Make cdp enable/disable global
x86/intel_rdt: Track the actual number of closids separately
x86/intel_rdt: Let resctrl change the resources's num_closid
x86/intel_rdt: Pass in the code/data/both configuration value when
parsing
x86/intel_rdt: Correct the closid when staging configuration changes
x86/intel_rdt: Allow different CODE/DATA configurations to be staged
x86/intel_rdt: Add a separate resource list for resctrl
x86/intel_rdt: Walk the resctrl schema list instead of the arch's
resource list
x86/intel_rdt: Move the schemata names into struct resctrl_schema
x86/intel_rdt: Stop using Lx CODE/DATA resources
x86/intel_rdt: Remove the CODE/DATA illusionary caches
x86/intel_rdt: Kill off alloc_enabled
x86/intel_rdt: Merge cdp enable/disable calls
arch/x86/kernel/cpu/intel_rdt.c | 298 +++++++-------------
arch/x86/kernel/cpu/intel_rdt.h | 161 ++++-------
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 142 +++++++---
arch/x86/kernel/cpu/intel_rdt_monitor.c | 78 ++---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 216 +++++++++-----
include/linux/resctrl.h | 166 +++++++++++
6 files changed, 621 insertions(+), 440 deletions(-)
create mode 100644 include/linux/resctrl.h
--
2.18.0
Powered by blists - more mailing lists