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 1D6D839A81B for ; Tue, 14 Apr 2026 14:55:05 +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=1776178507; cv=none; b=ENjizwk+dWKpSgWt8CqoeEDGEPwzWnPFVoWuEugS57qnBS8hHNrT7HJ3m/2kYlPQxEADhZmnqicLz0WHbBimhM4qkbreHISnJaeDsCtba/C0Pw0DKmmHUdtrG3dL1NpgFyVigOT7+NIaN7MpXGpszjC1WHH0HUeuaX8yBaRAYDM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776178507; c=relaxed/simple; bh=chXSryKCETVoNliQUZmY4qGgT8DjpwcYt9UNGMjia0o=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pH5Jt68eIFEGpd/VYgjfsJaDujyJmB233a8UbQ9N0AVPmNNBaDNsWtEbmy/lUQZGDzFpkkKJsSx71Sfe8+MkQlEJwyMfPtjiuNtjmd9OdLMAbKks7y6+3yjwglpWMt62S1yp6AkdHaTBmQsJ8v6Vragrvut5RJuhS797nLmytJQ= 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=OCQ+ZKd+; 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="OCQ+ZKd+" 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 B8A0B4420; Tue, 14 Apr 2026 07:54:59 -0700 (PDT) Received: from [10.1.196.46] (e134344.arm.com [10.1.196.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CBF4E3F641; Tue, 14 Apr 2026 07:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776178505; bh=chXSryKCETVoNliQUZmY4qGgT8DjpwcYt9UNGMjia0o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OCQ+ZKd+l737qiWRHz5CkK4m1bkqS0xIrty53d0zkMlPGmCpgLU7XUpWSLqMvThJK uxCo8N+jtw0E+XlWYdjwz1F6ALJK2xSlQieqes80cuEUiPhxuhojqaLI6XgYX1Qd4q 1IeZsDVmCp4ctpPsMw4Ums09wU2r7j7OqY15h+/A= Message-ID: <2e54280b-5154-457d-9e9a-69d25228bef9@arm.com> Date: Tue, 14 Apr 2026 15:55:02 +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: [PATCH v4 6/7] fs/resctrl: Document that automatic counter assignment is best effort To: Reinette Chatre , linux-kernel@vger.kernel.org Cc: tony.luck@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, fenghuay@nvidia.com, tan.shaopeng@fujitsu.com References: <20260326172551.1553871-1-ben.horgan@arm.com> <20260326172551.1553871-7-ben.horgan@arm.com> <8d51eef4-c52c-454c-b1fc-89549e544a13@intel.com> Content-Language: en-US From: Ben Horgan In-Reply-To: <8d51eef4-c52c-454c-b1fc-89549e544a13@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Reinette, On 3/27/26 16:24, Reinette Chatre wrote: > Hi Ben, > > On 3/26/26 10:25 AM, Ben Horgan wrote: >> 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/filesystems/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. >> >> + 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 > > "not have a counter assigned" -> "not have a counter assigned in all domains"? Ok, this is more correct. > >> + for details during such a scenario. > > While last_cmd_status would indicate a failure it is best for user space to > consult mbm_L3_assignments for the accurate counter assignment state ("the > details"). It is starting to sound like the documentation is directing user space > to last_cmd_status for state and I would like to avoid this. How about replacing > "Consult last_cmd_status ..." sentence with "Consult mbm_L3_assignments for > counter assignment states of the new group."? Makes sense. I agree that last_cmd_status should be keep as just a guide rather than over complicating the reporting. Thanks, Ben > >> + >> Example:: >> >> # echo 0 > /sys/fs/resctrl/info/L3_MON/mbm_assign_on_mkdir > > Reinette