Received-SPF: pass (google.com: domain of linux-kernel+bounces-96359-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20231201005720.235639-1-babu.moger@amd.com> <3fe3f235-d8a6-453b-b69d-6b7f81c07ae1@amd.com>
 <9b94b97e-4a8c-415e-af7a-d3f832592cf9@intel.com> <1ae73c9a-cec4-4496-86c6-3ffcef7940d6@amd.com>
 <32a588e2-7b09-4257-b838-4268583a724d@intel.com> <088878bd-7533-492d-838c-6b39a93aad4d@amd.com>
 <9b20589b-6220-4ae7-bfc4-4a826b7114b1@intel.com> <5ddb7031-a828-4001-bfdf-5477cb85e9ed@amd.com>
 <1738493b-3248-4c9e-82a8-1599a033440d@intel.com> <369ab28a-f3fa-4359-8e73-4dcf214c9b6e@amd.com>
 <54687d59-d0e4-4fe7-b25f-dc1fead01ea1@intel.com> <11487a31-908e-d474-50c6-65617d417deb@amd.com>
 <c73f444b-83a1-4e9a-95d3-54c5165ee782@intel.com> <55b545fd-2851-0d0f-ac37-ec59838fb4b4@amd.com>
 <1f366890-d9ff-4ac4-9af9-1ea3128a87fc@intel.com> <41ca7504-c3fb-ddb6-e149-4ff82019d678@amd.com>
 <CALPaoCi=PCWr6U5zYtFPmyaFHU_iqZtZL-LaHC2mYxbETXk3ig@mail.gmail.com>
 <1d3e8b68-28fa-419b-b129-0c39df34f718@intel.com> <CALPaoChJPkfrMgFDhtZqwK7O8=A71CKLzQjEMG6LbgB9RhdzvA@mail.gmail.com>
 <e90ce54c-a830-4ba5-8b28-aeef06705d01@intel.com>
In-Reply-To: <e90ce54c-a830-4ba5-8b28-aeef06705d01@intel.com>
From: Peter Newman <peternewman@google.com>
Date: Thu, 7 Mar 2024 15:14:25 -0800
Message-ID: <CALPaoChcJq5zoPchB2j0aM+nZpQe1xoo7w2QQUjtH+c58Yyxag@mail.gmail.com>
Subject: Re: [PATCH v2 00/17] x86/resctrl : Support AMD Assignable Bandwidth
 Monitoring Counters (ABMC)
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: babu.moger@amd.com, James Morse <james.morse@arm.com>, corbet@lwn.net, 
	fenghua.yu@intel.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, 
	dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, 
	paulmck@kernel.org, rdunlap@infradead.org, tj@kernel.org, 
	peterz@infradead.org, yanjiewtw@gmail.com, kim.phillips@amd.com, 
	lukas.bulwahn@gmail.com, seanjc@google.com, jmattson@google.com, 
	leitao@debian.org, jpoimboe@kernel.org, rick.p.edgecombe@intel.com, 
	kirill.shutemov@linux.intel.com, jithu.joseph@intel.com, kai.huang@intel.com, 
	kan.liang@linux.intel.com, daniel.sneddon@linux.intel.com, 
	pbonzini@redhat.com, sandipan.das@amd.com, ilpo.jarvinen@linux.intel.com, 
	maciej.wieczor-retman@intel.com, linux-doc@vger.kernel.org, 
	linux-kernel@vger.kernel.org, eranian@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Reinette,

On Thu, Mar 7, 2024 at 2:53=E2=80=AFPM Reinette Chatre
<reinette.chatre@intel.com> wrote:
>
> Hi Peter,
>
> On 3/7/2024 2:33 PM, Peter Newman wrote:
> > Hi Reinette,
> >
> > On Thu, Mar 7, 2024 at 12:41=E2=80=AFPM Reinette Chatre
> > <reinette.chatre@intel.com> wrote:
> >> I understood the proposed interface appeared to focus on one use case
> >> while the goal is to find an interface to support all requirements.
> >> With this proposed interface it it possible to make large scale change=
s
> >> with a single sysfs write.
> >
> > Ok I see you requested[1] one such example earlier.
> >
> > From what I've read, is this what you had in mind of reassigning 32
> > counters from the first 16 groups to the next?
> >
> > I had found that it's hard to get a single write() syscall out of a
> > string containing newlines, so I'm using one explicit call:
>
> Apologies but this is not clear to me, could you please elaborate?
>
> If you are referring to testing via shell you can try ANSI-C Quoting like=
:
>         echo -n $'c1/m1/00=3D_\nc2/m2/00=3D_\n'

The echo command uses buffered output through printf() and
putchar()[1]. The behavior of the buffering seems to be a write() call
after each newline, causing the kernel to see the request below as 32
individual commands.

>
> >
> > write([mbm_assign_control fd],
> > "/c1/m1/00=3D_;02=3D_;03=3D_;04=3D_;05=3D_;06=3D_;07=3D_;08=3D_;09=3D_;=
10=3D_;11=3D_;12=3D_;13=3D_;14=3D_;15=3D_\n"
> > "/c1/m2/00=3D_;01=3D_;02=3D_;03=3D_;04=3D_;05=3D_;06=3D_;07=3D_;08=3D_;=
09=3D_;10=3D_;11=3D_;12=3D_;13=3D_;14=3D_;15=3D_\n"
> > "/c1/m3/00=3D_;01=3D_;02=3D_;03=3D_;04=3D_;05=3D_;06=3D_;07=3D_;08=3D_;=
09=3D_;10=3D_;11=3D_;12=3D_;13=3D_;14=3D_;15=3D_\n"
> > [...]
> > "/c1/m14/00=3D_;01=3D_;02=3D_;03=3D_;04=3D_;05=3D_;06=3D_;07=3D_;08=3D_=
;09=3D_;10=3D_;11=3D_;12=3D_;13=3D_;14=3D_;15=3D_\n"
> > "/c1/m15/00=3D_;01=3D_;02=3D_;03=3D_;04=3D_;05=3D_;06=3D_;07=3D_;08=3D_=
;09=3D_;10=3D_;11=3D_;12=3D_;13=3D_;14=3D_;15=3D_\n"
> > "/c1/m16/00=3Dlt;01=3Dlt;02=3Dlt;03=3Dlt;04=3Dlt;05=3Dlt;06=3Dlt;07=3Dl=
t;08=3Dlt;09=3Dlt;10=3Dlt;11=3Dlt;12=3Dlt;13=3Dlt;14=3Dlt;15=3Dlt\n"
> > "/c1/m17/00=3Dlt;01=3Dlt;02=3Dlt;03=3Dlt;04=3Dlt;05=3Dlt;06=3Dlt;07=3Dl=
t;08=3Dlt;09=3Dlt;10=3Dlt;11=3Dlt;12=3Dlt;13=3Dlt;14=3Dlt;15=3Dlt\n"
> > "/c1/m18/00=3Dlt;01=3Dlt;02=3Dlt;03=3Dlt;04=3Dlt;05=3Dlt;06=3Dlt;07=3Dl=
t;08=3Dlt;09=3Dlt;10=3Dlt;11=3Dlt;12=3Dlt;13=3Dlt;14=3Dlt;15=3Dlt\n"
> > [...]
> > "/c1/m30/00=3Dlt;01=3Dlt;02=3Dlt;03=3Dlt;04=3Dlt;05=3Dlt;06=3Dlt;07=3Dl=
t;08=3Dlt;09=3Dlt;10=3Dlt;11=3Dlt;12=3Dlt;13=3Dlt;14=3Dlt;15=3Dlt\n"
> > "/c1/m31/00=3Dlt;01=3Dlt;02=3Dlt;03=3Dlt;04=3Dlt;05=3Dlt;06=3Dlt;07=3Dl=
t;08=3Dlt;09=3Dlt;10=3Dlt;11=3Dlt;12=3Dlt;13=3Dlt;14=3Dlt;15=3Dlt\n",
> > size);
>
> (so far no "/" needed as prefix)
>
> We could also consider some syntax to mean "all domains". For example,
> if no domain given then it can mean "all domains"?
> So, your example could possibly also be accomplished with a
>
>         c1/m1/=3D_\nc1/m2/=3D_\nc1/m3/=3D_\n [...] c1/m16/=3Dlt\nc1/m17/=
=3Dlt\nc1/m18/=3D_\n [...]
>
> Any thoughts?

Yes, that would be helpful. The AMD implementations we use typically
have 16 domains or more.

Thanks!
-Peter

[1] https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/echo.def