From nobody Thu Apr 2 22:05:15 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