From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A60DB3F2119 for ; Thu, 26 Mar 2026 17:26:02 +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=1774545963; cv=none; b=uRkk4hFdaE2SeJiP49THDKxdM8EeImYIvaHbZ5zRDzRAc8fxpwgAsM0kf4Csq2spesq+SDBeMBDZrqLJZDjlQiLxKfcEYXvrwCvJJ5KtLf8cU/DwFyZlB+Lt5WkGeVsODbfRIbYJUMDCUExtHSeI/sXtxsWfm+rLSBO3Bp4kpes= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545963; c=relaxed/simple; bh=r3jS0iMVJKol5bbCcmZNRj72n5eFPLHhD7IuoyM7mBA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RSViTSVKNIogZ5woQroSbh2XRJJJHYWhnMW2tLT4ZVqc+RhPdZSE6bUDOIFw1MWakPSbvVPhTMQafU9DwEZD2+vKKMCc0hOwHGGOw9liidjMNYKz9ZjnEmTEGS65NtWruZq+gPSt/bA71xcKC5jEM5npEwZd2qpwAQUgE4qwQw0= 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=oLzgbp0h; 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="oLzgbp0h" 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 265B72E96; Thu, 26 Mar 2026 10:25:56 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4293B3F641; Thu, 26 Mar 2026 10:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545962; bh=r3jS0iMVJKol5bbCcmZNRj72n5eFPLHhD7IuoyM7mBA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oLzgbp0h2SRD3+RuvOj30K/fi5Z07SSrlFWrUCgE5WXteg0TtWjY/moctm1r+WoBf bbyafgapFx2ZO7zoJ/8WtV67ncL11wPwqGWIpeZZaZrfaffuD/YwNAM3LWECxeAIxT G+6ZI61mwKEDlKeWNQ7l035cBxZuSlnf1OOoyj1g= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 1/7] fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs() Date: Thu, 26 Mar 2026 17:25:45 +0000 Message-ID: <20260326172551.1553871-2-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The error path in resctrl_mkdir_event_configs() is unnecessarily complicated. Simplify it to just return directly on error. Signed-off-by: Ben Horgan Reviewed-by: Reinette Chatre --- fs/resctrl/rdtgroup.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 5da305bd36c9..4753841c2ca3 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -2331,20 +2331,19 @@ static int resctrl_mkdir_event_configs(struct rdt_r= esource *r, struct kernfs_nod kn_subdir2 =3D kernfs_create_dir(kn_subdir, mevt->name, kn_subdir->mode,= mevt); if (IS_ERR(kn_subdir2)) { ret =3D PTR_ERR(kn_subdir2); - goto out; + return ret; } =20 ret =3D rdtgroup_kn_set_ugid(kn_subdir2); if (ret) - goto out; + return ret; =20 ret =3D rdtgroup_add_files(kn_subdir2, RFTYPE_ASSIGN_CONFIG); if (ret) - break; + return ret; } =20 -out: - return ret; + return 0; } =20 static int rdtgroup_mkdir_info_resdir(void *priv, char *name, --=20 2.43.0 From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A5110421884 for ; Thu, 26 Mar 2026 17:26:04 +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=1774545966; cv=none; b=WDhKzfa0PcEyb7qo6MPEsmQxt1BVHV31L6ZYM21w3dsktmNS+HP2+D54tw4z2CMFCbk/iyCNt88fnkjALYq033gE/TdYtMV+WY7VScRPGyEPJUmxPZ4S99iNiEC4+63Tkejx64RDKOV987qxip3EWiiK99WUvpfNjEt9Y9zraFA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545966; c=relaxed/simple; bh=+Fav2lw5Ue0Y+YKFeiS+A/r83UkeWzl+Hu4e89jAtb8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qbcdFT1bZ7s3NS1PAuWq84LtaHItENmPfgBjIdl7arqBnDO48NgIEBrYYJ3XX0dzU5fEWu4IQZSw+ocEs7iXYVguI2Wr5DjamoTGAPw9AjVSEcy8kfsJyVN4BG/eA4PmznApjjmRWx3iW+mbZccnxBUUznFl2C8qSQjMsuPfVNA= 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=Mj+EtUxz; 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="Mj+EtUxz" 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 2D0652E99; Thu, 26 Mar 2026 10:25:58 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 550A23F641; Thu, 26 Mar 2026 10:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545964; bh=+Fav2lw5Ue0Y+YKFeiS+A/r83UkeWzl+Hu4e89jAtb8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mj+EtUxzRzAyAx7fONZ8A/nXilBLwBpPq33MWVkh8XTCKzBLA3ZdJdbjIAYnZtzPM Vtc0ElTExBs1/5gHJubZZgJysMqiQizm+t9crKEu6eR07U8hhPeDI/79sN6pnIM745 8LQ9Ex6NOVUAdxUkuA5V6chAyS9I+BsXYmWSP+gk= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 2/7] x86,fs/resctrl: Make 'event_filter' files read only if they're not configurable Date: Thu, 26 Mar 2026 17:25:46 +0000 Message-ID: <20260326172551.1553871-3-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When the counter assignment mode is mbm_event resctrl assumes the MBM events are configurable and exposes the 'event_filter' files. These files live at info/L3_MON/event_configs//event_filter and are used to display and set the event configuration. The MPAM architecture has support for configuring the memory bandwidth utilization (MBWU) counters to only count reads or only count writes. However, In MPAM, this event filtering support is optional in the hardware (and not yet implemented in the MPAM driver) but MBM counter assignment is always possible for MPAM MBWU counters. In order to support mbm_event mode with MPAM, make the 'event_filter' files read only if the event configuration can't be changed. A user can still chmod the file and so also return early with an error from event_filter_write(). Introduce a new monitor property, mbm_cntr_configurable, to indicate whether or not assignable MBM counters are configurable. On x86, set this to true whenever mbm_cntr_assignable is true to keep existing behaviour. Signed-off-by: Ben Horgan --- Changes since v2: Use property, mbm_cntr_configurable, rather than arch hook Change the event_filter mode to read only in res_common_files[] Add resctrl_file_mode_init() and use in resctrl_l3_mon_resource_init() set mbm_cntr_configurable for x86 ABMC and mention in commit message --- arch/x86/kernel/cpu/resctrl/monitor.c | 1 + fs/resctrl/internal.h | 2 ++ fs/resctrl/monitor.c | 7 +++++++ fs/resctrl/rdtgroup.c | 11 ++++++++++- include/linux/resctrl.h | 16 +++++++++------- 5 files changed, 29 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/re= sctrl/monitor.c index 9bd87bae4983..794a6fb175e4 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -454,6 +454,7 @@ int __init rdt_get_l3_mon_config(struct rdt_resource *r) (rdt_cpu_has(X86_FEATURE_CQM_MBM_TOTAL) || rdt_cpu_has(X86_FEATURE_CQM_MBM_LOCAL))) { r->mon.mbm_cntr_assignable =3D true; + r->mon.mbm_cntr_configurable =3D true; cpuid_count(0x80000020, 5, &eax, &ebx, &ecx, &edx); r->mon.num_mbm_cntrs =3D (ebx & GENMASK(15, 0)) + 1; hw_res->mbm_cntr_assign_enabled =3D true; diff --git a/fs/resctrl/internal.h b/fs/resctrl/internal.h index 1a9b29119f88..48af75b9dc85 100644 --- a/fs/resctrl/internal.h +++ b/fs/resctrl/internal.h @@ -408,6 +408,8 @@ void __check_limbo(struct rdt_l3_mon_domain *d, bool fo= rce_free); =20 void resctrl_file_fflags_init(const char *config, unsigned long fflags); =20 +void resctrl_file_mode_init(const char *config, umode_t mode); + void rdt_staged_configs_clear(void); =20 bool closid_allocated(unsigned int closid); diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 49f3f6b846b2..8fec3dea33c3 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -1420,6 +1420,11 @@ ssize_t event_filter_write(struct kernfs_open_file *= of, char *buf, size_t nbytes ret =3D -EINVAL; goto out_unlock; } + if (!r->mon.mbm_cntr_configurable) { + rdt_last_cmd_puts("event_filter is not configurable\n"); + ret =3D -EPERM; + goto out_unlock; + } =20 ret =3D resctrl_parse_mem_transactions(buf, &evt_cfg); if (!ret && mevt->evt_cfg !=3D evt_cfg) { @@ -1884,6 +1889,8 @@ int resctrl_l3_mon_resource_init(void) resctrl_file_fflags_init("available_mbm_cntrs", RFTYPE_MON_INFO | RFTYPE_RES_CACHE); resctrl_file_fflags_init("event_filter", RFTYPE_ASSIGN_CONFIG); + if (r->mon.mbm_cntr_configurable) + resctrl_file_mode_init("event_filter", 0644); resctrl_file_fflags_init("mbm_assign_on_mkdir", RFTYPE_MON_INFO | RFTYPE_RES_CACHE); resctrl_file_fflags_init("mbm_L3_assignments", RFTYPE_MON_BASE); diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index 4753841c2ca3..fa5712db3778 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -2020,7 +2020,7 @@ static struct rftype res_common_files[] =3D { }, { .name =3D "event_filter", - .mode =3D 0644, + .mode =3D 0444, .kf_ops =3D &rdtgroup_kf_single_ops, .seq_show =3D event_filter_show, .write =3D event_filter_write, @@ -2213,6 +2213,15 @@ void resctrl_file_fflags_init(const char *config, un= signed long fflags) rft->fflags =3D fflags; } =20 +void resctrl_file_mode_init(const char *config, umode_t mode) +{ + struct rftype *rft; + + rft =3D rdtgroup_get_rftype_by_name(config); + if (rft) + rft->mode =3D mode; +} + /** * rdtgroup_kn_mode_restrict - Restrict user access to named resctrl file * @r: The resource group with which the file is associated. diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h index 006e57fd7ca5..06e8c72e8660 100644 --- a/include/linux/resctrl.h +++ b/include/linux/resctrl.h @@ -286,13 +286,14 @@ enum resctrl_schema_fmt { =20 /** * struct resctrl_mon - Monitoring related data of a resctrl resource. - * @num_rmid: Number of RMIDs available. - * @mbm_cfg_mask: Memory transactions that can be tracked when bandwidth - * monitoring events can be configured. - * @num_mbm_cntrs: Number of assignable counters. - * @mbm_cntr_assignable:Is system capable of supporting counter assignment? - * @mbm_assign_on_mkdir:True if counters should automatically be assigned = to MBM - * events of monitor groups created via mkdir. + * @num_rmid: Number of RMIDs available. + * @mbm_cfg_mask: Memory transactions that can be tracked when + * bandwidth monitoring events can be configured. + * @num_mbm_cntrs: Number of assignable counters. + * @mbm_cntr_assignable: Is system capable of supporting counter assignmen= t? + * @mbm_assign_on_mkdir: True if counters should automatically be assigned= to MBM + * events of monitor groups created via mkdir. + * @mbm_cntr_configurable: True if assignable counters are configurable. */ struct resctrl_mon { u32 num_rmid; @@ -300,6 +301,7 @@ struct resctrl_mon { int num_mbm_cntrs; bool mbm_cntr_assignable; bool mbm_assign_on_mkdir; + bool mbm_cntr_configurable; }; =20 /** --=20 2.43.0 From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ADAF43F2119 for ; Thu, 26 Mar 2026 17:26:06 +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=1774545968; cv=none; b=rWNvj6GgZbL41rJrogaFsC1x5phG0IE/7n6cT2mNkCBcaRCEOCKNzjkXgBh4TlC5xh/c6TmONSLYROEeRcXpfFbvoDB1TD6AAsk7PpsNLTpXjCI9iTW2CAlMZJGx8ynO4nQG9T6l2GdTxVkpqLP/vXO9y0xvCWrv1I4qgBnyvDI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545968; c=relaxed/simple; bh=9WRFiAuyxU+s3hWTEqddPln67W/ewp1pGFhWkyWHvnc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EH4z9TgM/NnnHbXH+EU8zslOdGadEWLSMowOL7UHQlLopSSWK9xs9B8Hv4f1ACHenxDajqE4JeNAXHXCmhI1PhAn0/4zad6xhDzsZrPo5ekj5ZCZqZpM3VQX+bOi/eb6RheyIScqSPHmgjpHBrqJp0LMYLy/4OQYxD0QNg2cQxo= 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=HxZfSzCo; 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="HxZfSzCo" 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 3BA982E9D; Thu, 26 Mar 2026 10:26:00 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5EC2A3F641; Thu, 26 Mar 2026 10:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545966; bh=9WRFiAuyxU+s3hWTEqddPln67W/ewp1pGFhWkyWHvnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HxZfSzCo31y9EYvpXmXsK/+6OLJiwfQXGNnVuB3O3FQ1c/XX1lr4FFHCRCKTsbak/ owYlgfFvTqPNWd1Mv8azwEZdu5ovTfd/mOHXTRknhp6r76HDBbEyLeIg2wCy1abwbn 88RcRdo3uFdyANes0ZkGgKYKPcmDqAcgOYad/rbU= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 3/7] fs/resctrl: Disallow the software controller when MBM counters are assignable Date: Thu, 26 Mar 2026 17:25:47 +0000 Message-ID: <20260326172551.1553871-4-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The software controller requires that for each MBA control there is one MBM counter per monitor group that is assigned to the event backing the software controller, as per mba_MBps_event. When mbm_event mode is in use, it is not guaranteed that any particular event will have an assigned counter. Currently, only AMD systems support counter assignment, but the MBA delay is non-linear and so the software controller is never supported anyway. On MPAM systems, the MBA delay is linear and so the software controller could be supported. The MPAM driver, unless a need arises, will not support the 'default' mbm_assign_mode and will always use the 'mbm_event' mode for memory bandwidth monitoring. Rather than develop a way to guarantee the counter assignment requirements needed by the software controller, take the pragmatic approach. Don't allow the software controller to be used at the same time as 'mbm_event' mode. As MPAM is the only relevant architecture and it will use 'mbm_event' mode whenever there are assignable MBM counters, for simplicity's sake, don't allow the software controller when the MBM counters are assignable. Implement this by failing the mount if the user requests the software controller, the mba_MBps option, and the MBM counters are assignable. Signed-off-by: Ben Horgan --- fs/resctrl/rdtgroup.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c index fa5712db3778..7ef316b24a41 100644 --- a/fs/resctrl/rdtgroup.c +++ b/fs/resctrl/rdtgroup.c @@ -2528,7 +2528,8 @@ static bool supports_mba_mbps(void) =20 return (resctrl_is_mbm_enabled() && r->alloc_capable && is_mba_linear() && - r->ctrl_scope =3D=3D rmbm->mon_scope); + r->ctrl_scope =3D=3D rmbm->mon_scope && + !rmbm->mon.mbm_cntr_assignable); } =20 /* @@ -2943,7 +2944,7 @@ static int rdt_parse_param(struct fs_context *fc, str= uct fs_parameter *param) ctx->enable_cdpl2 =3D true; return 0; case Opt_mba_mbps: - msg =3D "mba_MBps requires MBM and linear scale MBA at L3 scope"; + msg =3D "mba_MBps requires dedicated MBM counters and linear scale MBA a= t L3 scope"; if (!supports_mba_mbps()) return invalfc(fc, msg); ctx->enable_mba_mbps =3D true; --=20 2.43.0 From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1CF5E41B366 for ; Thu, 26 Mar 2026 17:26:08 +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=1774545970; cv=none; b=Xd7jBN0W0vfUH1yO3xidaeiOlCazbYI67bT/aodtIvkNad2u+UBZnUho4OW9n8tQttjFWn78L0Oa5IRz6FK89tf79YmoFv+RzGq/4irRzvBbqEZWme33GATl+H2kUglyNrVMYL9X34e2B9SVdy1hW0gGyFSTZMkugL/26Th9A50= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545970; c=relaxed/simple; bh=GHwXODuDHTkuvstiHLr9nJaIWNQHcUF6SOefsZqplbk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N7zcPYKaswSy+ie+NvuyLtU3HLOVuYt8vq1HJ4HYzO1uRxELOV4QrlqeyjUgs1617IbE5Rj1eLdTGhs2TyQjC22iRgs+gq+0nGQBCpzIDvTJ7xc3hraMh7RjYkpjMxERbbdkBbNYywxXDTOdbFF+3MSXDadLlYbEr8kPRVUO0CE= 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=p44CDDnA; 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="p44CDDnA" 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 4453F2EC5; Thu, 26 Mar 2026 10:26:02 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 69B5C3F641; Thu, 26 Mar 2026 10:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545968; bh=GHwXODuDHTkuvstiHLr9nJaIWNQHcUF6SOefsZqplbk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p44CDDnAkDVYcdT3XcF+Mvy14JERDimtPId3aNcTrF11J0ftLDFnXy7j+qORo7Lmi 5hNZ63DkSjhPqGDMn1ZXhNuBp2269OcVS7ff5Zldud58uj6rUew13ieazeVD4gvsuA PBsP9O0QMEYRuLA0kBBMGrELt0Qrs60r8tN+8Y+0= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 4/7] x86,fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed' Date: Thu, 26 Mar 2026 17:25:48 +0000 Message-ID: <20260326172551.1553871-5-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit 3b497c3f4f04 ("fs/resctrl: Introduce the interface to display monitoring = modes") introduced CONFIG_RESCTRL_ASSIGN_FIXED but left adding the Kconfig entry until it was necessary. The counter assignment mode is fixed in MPAM, even when there are assignable counters, and so addressing this is needed to support MPAM. To avoid the burden of another Kconfig entry, replace CONFIG_RESCTRL_ASSIGN_FIXED with a new property in 'struct resctrl_mon', 'mbm_cntr_assign_fixed'. To enable better user reporting check the new property in resctrl_mbm_assign_mode_write(). Signed-off-by: Ben Horgan --- Changes since v2: Change to a resctrl_mon property rather than a arch hook Update the commit message to mention the property --- fs/resctrl/monitor.c | 8 +++++++- include/linux/resctrl.h | 2 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 8fec3dea33c3..6afa2af26ff7 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -1454,7 +1454,7 @@ int resctrl_mbm_assign_mode_show(struct kernfs_open_f= ile *of, else seq_puts(s, "[default]\n"); =20 - if (!IS_ENABLED(CONFIG_RESCTRL_ASSIGN_FIXED)) { + if (!r->mon.mbm_cntr_assign_fixed) { if (enabled) seq_puts(s, "default\n"); else @@ -1505,6 +1505,12 @@ ssize_t resctrl_mbm_assign_mode_write(struct kernfs_= open_file *of, char *buf, } =20 if (enable !=3D resctrl_arch_mbm_cntr_assign_enabled(r)) { + if (r->mon.mbm_cntr_assign_fixed) { + ret =3D -EINVAL; + rdt_last_cmd_puts("Counter assignment mode is not configurable\n"); + goto out_unlock; + } + ret =3D resctrl_arch_mbm_cntr_assign_set(r, enable); if (ret) goto out_unlock; diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h index 06e8c72e8660..a986daf5f2ef 100644 --- a/include/linux/resctrl.h +++ b/include/linux/resctrl.h @@ -294,6 +294,7 @@ enum resctrl_schema_fmt { * @mbm_assign_on_mkdir: True if counters should automatically be assigned= to MBM * events of monitor groups created via mkdir. * @mbm_cntr_configurable: True if assignable counters are configurable. + * @mbm_cntr_assign_fixed: True if the counter assignment mode is fix. */ struct resctrl_mon { u32 num_rmid; @@ -302,6 +303,7 @@ struct resctrl_mon { bool mbm_cntr_assignable; bool mbm_assign_on_mkdir; bool mbm_cntr_configurable; + bool mbm_cntr_assign_fixed; }; =20 /** --=20 2.43.0 From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 03DCC3FBEAB for ; Thu, 26 Mar 2026 17:26:11 +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=1774545976; cv=none; b=jEwdxyL8UKPc6wCJoeCV9Tvg6FECgbkZWHLGS/l2K2PdelJAM3UWhRm3rHVOxiAEIRL+wfjkj4MxKZSivxsa210jgR/it0srh0i7J4R37eoENrkWD2GOrI5GUsjlo2w3fedKarH7xvCS+Ax2Holz/AaNupxIKu20eBi3Dx5ngdk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545976; c=relaxed/simple; bh=Ajmj6VxV7RaPfqEPN48GTMrq6FnkYbkdyyyRKnZHPt4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LMM+t666s+zqoi9JWBH8VlGPoBszml/128qPcySJV8M1dC2IwAFgFYJPjpRCc66cZwcrQq74gQjRPfglx2S5q0lSd4/ImOZSpy/DPEjFscyBbAz1vFN4+CiRKiDi2CWjJrcGYMtj+dOp9QWcs2XstQEGjTqm3Y5k4XcGzdVVf80= 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=LPZVXLGf; 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="LPZVXLGf" 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 4F28C2EC6; Thu, 26 Mar 2026 10:26:04 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 74A063F641; Thu, 26 Mar 2026 10:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545970; bh=Ajmj6VxV7RaPfqEPN48GTMrq6FnkYbkdyyyRKnZHPt4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LPZVXLGfoicc8YIWS6mcc5KxD5fhYOMAiceFA7nv+HeMNxv5zN7YbK2e0lAy5wM4a SZax+jbhZDMT+MgCJIaWsEYGTsoC2ybGOrLMrOz/u6pMy/gilym9Jhglfd3Z0HHZ6f JvBgd1EV+Cjx7rNaubbran7JvSOTvyUgR7/9lYfo= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 5/7] fs/resctrl: Continue counter allocation after failure Date: Thu, 26 Mar 2026 17:25:49 +0000 Message-ID: <20260326172551.1553871-6-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In mbm_event mode, with mbm_assign_on_mkdir set to 1, when a user creates a new CTRL_MON or MON group resctrl will attempt to allocate counters for each of the supported mbm events on each resctrl domain. As counters are limited, these allocations may fail. If an mbm_total_event counter allocation fails then the mbm_total_event counter allocations for the remaining domains are skipped and then the mbm_local_event counter allocations are made. These failures don't cause the group allocation to fail but the user should still be aware of them. A message for each attempted allocation is reported in last_cmd_status but in order to fully interpret that information the user needs to know what was skipped. This is knowable as the domain list is sorted but it is undesirable to rely on such implementation details. Writes to mbm_L3_assignments using the wildcard format, :*=3De, will also skip counter allocation after any counter allocation failure. Leading once again to counters that are allocated but have no corresponding message in last_cmd_status to indicate that. When a new group is created always attempt to allocate all the counters requested. Similarly, when a a wildcard assign operation is written to mbm_L3_assignments, attempt to allocate all counters requested by that particular operation. For mbm_L3_assignments, continue to return an error on counter allocation failure and for a write specifying multiple assign operations continue to abort after the first failing assign operation. Signed-off-by: Ben Horgan --- fs/resctrl/monitor.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/fs/resctrl/monitor.c b/fs/resctrl/monitor.c index 6afa2af26ff7..3f33fff8eb7f 100644 --- a/fs/resctrl/monitor.c +++ b/fs/resctrl/monitor.c @@ -1209,9 +1209,10 @@ static int rdtgroup_alloc_assign_cntr(struct rdt_res= ource *r, struct rdt_l3_mon_ * NULL; otherwise, assign the counter to the specified domain @d. * * If all counters in a domain are already in use, rdtgroup_alloc_assign_c= ntr() - * will fail. The assignment process will abort at the first failure encou= ntered - * during domain traversal, which may result in the event being only parti= ally - * assigned. + * will fail. When attempting to assign counters to all domains, carry on = trying + * to assign counters after a failure since only some domains may have cou= nters + * and the goal is to assign counters where possible. If any counter assig= nment + * fails, return the error from the last failing assignment. * * Return: * 0 on success, < 0 on failure. @@ -1224,9 +1225,11 @@ static int rdtgroup_assign_cntr_event(struct rdt_l3_= mon_domain *d, struct rdtgro =20 if (!d) { list_for_each_entry(d, &r->mon_domains, hdr.list) { - ret =3D rdtgroup_alloc_assign_cntr(r, d, rdtgrp, mevt); - if (ret) - return ret; + int err; + + err =3D rdtgroup_alloc_assign_cntr(r, d, rdtgrp, mevt); + if (err) + ret =3D err; } } else { ret =3D rdtgroup_alloc_assign_cntr(r, d, rdtgrp, mevt); --=20 2.43.0 From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 45FA140F8C2 for ; Thu, 26 Mar 2026 17:26:13 +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=1774545980; cv=none; b=bnIjdnUTqiVqj0Dy+VrTemGhRF02HIMEb6zo9FwfFN0U/ySOWr0eOBR/OFMDSJ9d09w3Cj1MKBfxc5MfXXuWdHb+h7wbCc2ELxjgu4u+JJF41ueIY0uDqIooeNS/osarIlw5W3wScPadWovaIWfamW8acg3o7GNd/GTrlF/D7l0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545980; c=relaxed/simple; bh=eB4Cg1lvdQDq5ESyLcH3wG2Wkyfzy2z3s3q7NpvP/Fk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NgRg3xHLh5SUfKQ0h50/4W4hGHA6KFg0xiuBCDVYSEe3CpgXiM2T1X0Jc+Ar8T2YkR30qTv0LK+vt4YXbPAKPQcbGiJe6p6Csr6EHp2fLlUnhkB8wQ3CKPRfv1W/TwmS+cf0NTT2KCMHIta2L2N5cOf+P55JaSZALNPgm2QbllA= 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=Og1bG2nV; 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="Og1bG2nV" 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 69DED2BCB; Thu, 26 Mar 2026 10:26:06 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 7F6163F641; Thu, 26 Mar 2026 10:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545972; bh=eB4Cg1lvdQDq5ESyLcH3wG2Wkyfzy2z3s3q7NpvP/Fk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Og1bG2nVs9nE/iekD0MYb80bNv07jI4IdBV2/owh6ztidFXjCG5gG3QeX3QN4uMz3 8AOq7okIc8A7pwesFvOiOvqn2yumnjqv9un8in0qt09aWeO3L3lsccSVRGfhWt0636 DL390z6IIXcLYQOaJltNUsml33cTl3grKxS7nFzY= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 6/7] fs/resctrl: Document that automatic counter assignment is best effort Date: Thu, 26 Mar 2026 17:25:50 +0000 Message-ID: <20260326172551.1553871-7-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When using automatic counter assignment it's useful for a user to know which counters they can expect to be assigned on group creation. Document that automatic counter assignment is best effort and how to discover any assignment failures. Suggested-by: Reinette Chatre Signed-off-by: Ben Horgan --- Hi Reinette, I've just taken your suggested paragraph with a minor tweak (s/scenario/a scenario/) and moved it above the examples as I think it makes sense to keep examples last in each section. --- Documentation/filesystems/resctrl.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesyst= ems/resctrl.rst index ba609f8d4de5..68cada238844 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -472,6 +472,12 @@ with the following files: "1": Auto assignment is enabled. =20 + Automatic counter assignment is done with best effort. If auto + assignment is enabled but there are not enough available counters then + monitor group creation could succeed while one or more events belonging + to the group may not have a counter assigned. Consult last_cmd_status + for details during such a scenario. + Example:: =20 # echo 0 > /sys/fs/resctrl/info/L3_MON/mbm_assign_on_mkdir --=20 2.43.0 From nobody Thu Apr 2 20:21:59 2026 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A064C42317F for ; Thu, 26 Mar 2026 17:26:16 +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=1774545981; cv=none; b=BEIbIJ3kkIWnqMtN0kaP2D+r9MoMjFWnFh3xUhGYtzk3Ndkuw/p6/XhfcPb0eOX1mYFlVi0zexrUCLYaE0idNv878d7Ymp8wYssBi6D25aKRbnkoKds0moFvv672aTrlGCQN+JDVFs5zYnhvXWvyCSsuYN7a2Pc+snk8Pe2d4Ak= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774545981; c=relaxed/simple; bh=qHq1BfTzNtkcC22P47lbhNCUQkdr6+ASSkdDWu1VoO0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XPCxknBSksIA9nU2oJvJy9WaQRFmfmhSlpNpFeZBIHtmIUy+em5AFKuCNS5HnAWREo2Kq2+MBQy0ok/pmLWjnHTnCcbe4Pkxm6op4NngG/gBtSOwb9ZijrRTO9TwFj3BUyFGfO4D7ioA9zc4y/rnjDF5iyNZmt5pXoeoFYbyYGU= 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=YqjQCDy6; 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="YqjQCDy6" 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 65E572E96; Thu, 26 Mar 2026 10:26:08 -0700 (PDT) Received: from e134344.cambridge.arm.com (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 89D0E3F641; Thu, 26 Mar 2026 10:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1774545974; bh=qHq1BfTzNtkcC22P47lbhNCUQkdr6+ASSkdDWu1VoO0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YqjQCDy6b3zNsyjDjhVpHq3+yED/UGnxMekZ7y9wzmfu+D7ByKLQ28Z1Oqi9dMHsd JtQtgcdRSR5RVZntcDzx2r0l0T8nx85XklTNj2Atc3O5ZeoeGJMuUdEfKSwSc3iXke d2g4wO2q5h5VRNETIMp1YE4klP41S8wEA/SrtFxo= From: Ben Horgan To: linux-kernel@vger.kernel.org Cc: tony.luck@intel.com, reinette.chatre@intel.com, Dave.Martin@arm.com, james.morse@arm.com, babu.moger@amd.com, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ben.horgan@arm.com, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com Subject: [PATCH v4 7/7] fs/resctrl: Document tasks file behaviour for task id 0 and idle tasks Date: Thu, 26 Mar 2026 17:25:51 +0000 Message-ID: <20260326172551.1553871-8-ben.horgan@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260326172551.1553871-1-ben.horgan@arm.com> References: <20260326172551.1553871-1-ben.horgan@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When 0 is written to the tasks file it is interpreted as the current task in rdtgroup_move_task(). The task_struct for each CPUs idle task has pid set to 0 and, on x86, the closid to RESCTRL_RESERVED_CLOSID and rmid to RESCTRL_RESERVED_RMID. Equivalently, on MPAM platforms, thread_info->mpam_partid_pmg is encoded with PARTID and PMG set to RESCTRL_RESERVED_CLOSID and RESCTRL_RESERVED_RMID, respectively. As there is no interface to change these from the default, the resctrl configuration for the idle tasks is fixed and they always behave equivalently to a task in the default tasks file and so take their configuration from the cpus files. On read of the tasks file, show_rdt_tasks() filters out any 0 pid. Hence, a task id of 0 is never shown in the tasks file and the idle tasks are not represented either. Document the user visible behaviour. Signed-off-by: Ben Horgan --- I have confirmed this experimentally on an MPAM platform. --- Documentation/filesystems/resctrl.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesyst= ems/resctrl.rst index 68cada238844..3ec6b3b1b603 100644 --- a/Documentation/filesystems/resctrl.rst +++ b/Documentation/filesystems/resctrl.rst @@ -568,6 +568,11 @@ All groups contain the following files: then the task must already belong to the CTRL_MON parent of this group. The task is removed from any previous MON group. =20 + When writing to this file, a task id of 0 is interpreted as the + task id of the currently running task. On reading the file, a task + id of 0 will never be shown and there is no representation of the + idle tasks. Instead, a CPU's idle task is always considered as a + member of the group owning the CPU. =20 "cpus": Reading this file shows a bitmask of the logical CPUs owned by --=20 2.43.0