From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DC2EB3A6B82 for ; Wed, 5 Aug 2026 16:59:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785949189; cv=none; b=ZJY/iafaZcJSRhmpPUEV70gRh0gO1J/XoFUlGxmF1ctvjsBM6xxte+4YObJMxhiPMFt4wSxRFuYb0pgmNakFuR1Iwfcwuq9rIlS0UttMIbGX9ZoNf4Y80USQr0FVWDAABN6Z9SGQ6mUc0+FhmeoFLMxvcFnVOeTAlf3kX2Nqxko= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785949189; c=relaxed/simple; bh=SDmG1y+qCu7eMdMzJgePaCLFxDGOwhu0MVu8G3cRa20=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Zr8vWUHhysOL3rM9e8RrV0/2YnGWJMLhp6s/GwmhS1socAQKsvkpyx5J5gJyxO5sI4C71opQ/y+lIS2OpAeAqDYQ9H3OtTMaI6dFA7zE2jPPIkUOrWCx0kkQsPYO+QuVMTCln1E1TvRTuFaL7DcfcSFwJCIkWWe0ARR6Rdg1eW4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=DluOXo3B; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="DluOXo3B" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CDDF8153B; Wed, 5 Aug 2026 09:59:40 -0700 (PDT) Received: from [10.2.212.8] (e134344.arm.com [10.2.212.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B59C73F632; Wed, 5 Aug 2026 09:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1785949184; bh=SDmG1y+qCu7eMdMzJgePaCLFxDGOwhu0MVu8G3cRa20=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=DluOXo3BO2weWMYy2re+5JVXOjZG5qsLirVuHYddKu6LJ3r7lJltsjRT5GcfEOib9 fS4JIwAdFasPPatOYyz7YSdEMThy4D6kVsiOZfMznwMpaKA9NJruoLI1GhFVa9yKQ3 A/dmpqYyvUzACPHoyoV9p1ykZc3vf6+U0x5ysJaM= Message-ID: Date: Wed, 5 Aug 2026 17:59:41 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Thunderbird Daily Subject: Re: [RFC v2] arm,x86,fs/resctrl: Generic schema description Proof of Concept To: Reinette Chatre , Tony Luck , James Morse , Dave Martin , Babu Moger , Drew Fustini , Fenghua Yu , Chen Yu Cc: Borislav Petkov , Thomas Gleixner , Dave Hansen , Peter Newman , "x86@kernel.org" , "linux-kernel@vger.kernel.org" References: Content-Language: en-US From: Ben Horgan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 8/4/26 06:26, Reinette Chatre wrote: > Hi Everybody, > > I understand that folks are eager for this work to settle so that features that > depend on it can make progress. > > I do have a request if you have a feature that depends on this PoC: > > Please do not fork this PoC and keep changes to the PoC code in your fork > to meet the requirements of the feature you are working on. This is resulting > in duplicate (even triplicate) changes to PoC floating around. Instead, > please collaborate on this PoC by responding to the patches that need changes/fixes > to support your feature. If the patches do not exist yet, please participate in > the discussions that plan these changes so the work adding the discussed features > is not duplicated. If you already have the code, please feel free to send as fixups. > Doing so will help this PoC to settle faster and help meet the requirements of the > feature(s) a couple of folks are working on. > > RFC v1: https://lore.kernel.org/lkml/aab804b9-e8b5-40ad-a85b-af7033391243@intel.com/ > git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v1 > > RFC v2 of this PoC can be found at: > git://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git branch resctrl/controls_rfc_v2 > > The list of changes is long. For an overview of the new interfaces, please see the new > documentation patch: > https://git.kernel.org/pub/scm/linux/kernel/git/reinette/linux.git/patch/?id=2e2d0140e857eae2ba3e71e8d9c595897649599a > > Remaining Opens: > --------------- > - MPAM only compile tested. > - Only "SAMPLE" code provided for x86 to demonstrate emulated controls. > - Architecture should take care to restore control value of legacy control when > switching mode from "native" to "legacy". This may be complicated by a > legacy control backed by multiple native controls and thus best handled by > architecture. This adds a complication that resctrl cannot promise that > switching between control modes will not be destructive since a reverse mapping > may not exist. > - When switching control mode to native the top level control info files > stop returning information. This could be considered "work as intended"? > - Add relationships between controls. For example, cannot set "MIN" control > value to be larger than "MAX. Unclear how to do this in resctrl fs when > considering that the relationship may span between enabled and disabled > controls. This is potentially something that needs to be managed by architecture > and thus potentially without a consistent failure to user space. > > Changes since RFC v1: > -------------------- > There are many changes since RFC v1 since I aimed to address all feedback > (but please see the deferred/dropped list below). If I missed anything it > was not intentional. Please feel free to point it out to me. > > User visible changes: > -------------------- > - Expose bitmap control properties to user space. > -- Only expose two properties: > - resctrl_ctrl_bitmap::min_cbm_bits exposed via new file "min_bits". > This drops the familiar "cbm" term to not make the control specific > to capacity. > - resctrl_ctrl_bitmap::cbm_len exposed via "max" file > -- While "shareable_bits" is technically a bitmap control property this does > seem an opportunity to deprecate it since the IO alloc support proved > that it does not accurately represent shared allocations, "bit_usage" > is the best for that. > - Add support for control flags with "linear" as first flag of the "scalar" > control and "sparse" the first flag of the "bitmap" control. > Include flags in output of the "type" file. > Suggested by Chenyu: https://lore.kernel.org/lkml/90ae82da-02b2-4058-8c1e-f16df3226d8a@intel.com/ > - Add a "default" field to a control using the "reset_val" name suggested > by Drew and return that instead of always using "max" for the scalar control. > The "MIN" control can return its minimum value as default. > Suggested by Ben in https://lore.kernel.org/lkml/29c95b69-e1a4-46b1-ab8b-45c09308b924@arm.com/ > Use case from Drew: https://lore.kernel.org/lkml/aiCBratZchVFVhws@gen8/ > Drew suggested name as "reset_val" https://lore.kernel.org/lkml/aiOrznnZjTGywMna@thelio> > - Change "resource_schemata" to "schemata". > Fenghua: https://lore.kernel.org/lkml/d0f84cef-58f5-4b84-8171-a0dfe8fa6829@nvidia.com/ > - Fix the control alignment. (Chenyu and Tony) > - Drop the "per control" scope. Move the "scope" back to being per-resource and > do not expose a per control "scope" file. This helps to support new resources > like node scoped MBA that cannot emulate the legacy MB control. Also > supports emulated controls by ensuring that all controls associated with > a resource have the same scope. > - Support emulating legacy control. > - Support multiple backing controls for a legacy control. > - Expose new per-resource "control_mode" file that user space can use to > switch between legacy and native controls. Only the enabled controls > are shown to user in schemata file. > - The new "native" control mode is only supported for the MBA resource. > The solution is generic but there are implications for, for example, the > resctrl features that rely on the legacy cache control (cache pseudo-locking > and IO alloc). Defer support for other resource since there are no immediate > plans to have, for example, the legacy cache control backed by something else. > - Architecture differences imply a lot of architecture flexibility in > support for emulating controls. > Architecture can expect resctrl fs to only stage control values in > controls that are enabled. Within architecture there could be rules > that determine what to program based on the control's emulated controls > or it could dynamically program update callbacks when the user changes > the control mode. RFC includes sample code identified by "SAMPLE" for the > latter that demonstrates one way to solve the x86 variant where the hardware > self supports both legacy and finer grained controls. > - The top level legacy control property files stop returning data when > the mode switches to "native". > - Draft of documentation that describes multiple controls and emulated > controls. > - Fix Intel MBA tolerance to be 10 to match the "round-up" implementation. > > Changes not user visible: > ------------------------- > - Rebase on tip x86/cache with following applied on top: > "x86,fs/resctrl: Improve resctrl quality and consistency" > https://lore.kernel.org/lkml/cover.1782857711.git.reinette.chatre@intel.com/ > "x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch" > https://lore.kernel.org/lkml/20260709093111.367851-1-ben.horgan@arm.com/ > - Fix initialization of controls list in MPAM. (Ben) > - Dan Carpenter reported an issue with missing unlocks in > rdt_bit_usage_show() that was resolved as part of rebase on top of the > new info_kn_lock()/info_kn_unlock() helpers. > - Drop "mpam,x86,fs/resctrl: Make memory bandwidth delay a resource > property" so that memory bandwidth delay linear flag can be a control flag > instead. > - Separate adding the control to struct msr_param from the change that > makes hardware update functions part of control. > ("x86/resctrl: Make control update properties part of the control") to > create new patch that is moved earlier in series to support bandwidth > linear flag property being part of control. > New patch: "x86/resctrl: Include control with information controlling hardware change" > - Rename the controls to match their type to reduce confusion. > Suggested by Chenyu: https://lore.kernel.org/lkml/773353e8-b2a7-4c20-b6fa-195b0b301107@intel.com/ > New names: > struct resctrl_membw -> struct resctrl_ctrl_scalar > struct resctrl_cache -> struct resctrl_ctrl_bitmap > resctrl_ctrl::membw -> resctrl_ctrl::scalar > resctrl_ctrl::cache -> resctrl_ctrl::bitmap > - Switch subject prefix to be "arm,x86,fs/resctrl: ..." when changing both > architectures and resctrl fs code. > - Switch to MPAM subject prefix of "arm_mpam: resctrl:" when only changing > MPAM code. > > Changes deferred/dropped: > ------------------------ > - Let "scope" form part of the control name. > Drop this since the current plan is to have the scope be part of the resource > name for new resources. > - Introduce new per-control "status" that can be "enabled" or "disabled". > Drop this. While controls now have an "enabled" or "disabled" state internally, > this is not exposed to user space via a file. Instead, the "enabled" or > "disabled" state is exposed to user space via the entries appearing in schemata > file. This simplifies the subtleties when the hardware self supports both > legacy and finer grained interfaces (aka RDT's region-aware). > - Defer emulated control support for cache controls. > - Supporting different monitoring scope is not part of this PoC. > > Any feedback is appreciated. Just given a go at running this on a model with MPAM and I can mount resctrl with this small patch to initialise the emulated_by lists so that list_empty() behaves. diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c index 21dcbf5764cc..638095649151 100644 --- a/drivers/resctrl/mpam_resctrl.c +++ b/drivers/resctrl/mpam_resctrl.c @@ -1018,6 +1018,7 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res) case RDT_RESOURCE_L3: mpam_ctrl->r_ctrl.type = RESCTRL_CTRL_BITMAP; mpam_ctrl->r_ctrl.name = RESCTRL_CTRL_NAME_DEF; + INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by); INIT_LIST_HEAD_RCU(&mpam_ctrl->r_ctrl.domains); __set_bit(RESCTRL_BITMAP_FLAG_SPARSE, mpam_ctrl->r_ctrl.bitmap.flags); mpam_ctrl->r_ctrl.bitmap.cbm_len = class->props.cpbm_wd; @@ -1048,6 +1049,7 @@ static int mpam_resctrl_control_init(struct mpam_resctrl_res *res) r->ctrl_scope = RESCTRL_L3_CACHE; mpam_ctrl->r_ctrl.type = RESCTRL_CTRL_SCALAR; mpam_ctrl->r_ctrl.name = RESCTRL_CTRL_NAME_DEF; + INIT_LIST_HEAD(&mpam_ctrl->r_ctrl.emulated_by); INIT_LIST_HEAD_RCU(&mpam_ctrl->r_ctrl.domains); r->bw_throttle_mode = THREAD_THROTTLE_UNDEFINED; I haven't a good look at the code yet but from the list of changes you have above it seems to be heading in the right direction. Thank you for all the work on this and for always considering MPAM in the design. I'm out of office for a couple of weeks but I'll give this a better look when I'm back. One little thing that seems odd is that control_mode shows 'native' as an option even if there are no emulated controls. $ cat info/L3/control_mode [legacy] native Thanks, Ben > > Reinette