From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
Peter Newman <peternewman@google.com>
Cc: 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
Subject: Re: [PATCH v2 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)
Date: Thu, 7 Mar 2024 21:50:21 -0600 [thread overview]
Message-ID: <46065d68-8334-4b76-bc68-c2695e7b98de@amd.com> (raw)
In-Reply-To: <e90ce54c-a830-4ba5-8b28-aeef06705d01@intel.com>
Hi Reinette/Peter,
On 3/7/24 16:53, Reinette Chatre wrote:
> Hi Peter,
>
> On 3/7/2024 2:33 PM, Peter Newman wrote:
>> Hi Reinette,
>>
>> On Thu, Mar 7, 2024 at 12:41 PM Reinette Chatre
>> <reinette.chatre@intel.com> wrote:
>>>
>>> Hi Peter,
>>>
>>> On 3/7/2024 10:57 AM, Peter Newman wrote:
>>>> Hi Babu,
>>>>
>>>> On Mon, Mar 4, 2024 at 2:24 PM Moger, Babu <bmoger@amd.com> wrote:
>>>>> Based on our discussion, I am listing few examples here. Let me know if
>>>>> I missed something.
>>>>>
>>>>> mount -t resctrl resctrl /sys/fs/resctrl/
>>>>>
>>>>> 1. Assign both local and total counters to default group on domain 0 and 1.
>>>>> $echo "//00=lt;01=lt" > /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>>
>>>>> $cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>> //00=lt;01=lt
>>>>>
>>>>> 2. Assign a total event to mon group inside the default group for both
>>>>> domain 0 and 1.
>>>>>
>>>>> $mkdir /sys/fs/resctrl/mon_groups/mon_a
>>>>> $echo "/mon_a/00+t;01+t" >
>>>>> /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>>
>>>>> $cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>> //00=lt;01=lt
>>>>> /mon_a/00=t;01=t
>>>>>
>>>>> 3. Assign a local event to non-default control mon group both domain 0
>>>>> and 1.
>>>>> $mkdir /sys/fs/resctrl/ctrl_a
>>>>> $echo "/ctrl_a/00=l;01=l" >
>>>>> /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>>
>>>>> $cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>> //00=lt;01=lt
>>>>> /mon_a/00=t;01=t
>>>>> /ctrl_a/00=l;01=l
>>>>>
>>>>> 4. Assign a both counters to mon group inside another control
>>>>> group(non-default).
>>>>> $mkdir /sys/fs/resctrl/ctrl_a/mon_ab/
>>>>> $echo "ctrl_a/mon_ab/00=lt;01=lt" >
>>>>> /sys/fs/resctrl/nfo/L3_MON/mbm_assign_contro
>>>>>
>>>>> $cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>> //00=lt;01=lt
>>>>> /mon_a/00=t;01=t
>>>>> /ctrl_a/00=l;01=l
>>>>> ctrl_a/mon_ab/00=lt;01=lt
>>>>>
>>>>> 5. Unassign a counter to mon group inside another control
>>>>> group(non-default).
>>>>> $echo "ctrl_a/mon_ab/00-l;01-l" >
>>>>> /sys/fs/resctrl/nfo/L3_MON/mbm_assign_control
>>>>>
>>>>> $cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>> //00=lt;01=lt
>>>>> /mon_a/00=t;01=t
>>>>> /ctrl_a/00=l;01=l
>>>>> ctrl_a/mon_ab/00=t;01=t
>>>>>
>>>>> 6. Unassign all the counters on a specific group.
>>>>> $echo "ctrl_a/mon_ab/00=_" >
>>>>> /sys/fs/resctrl/nfo/L3_MON/mbm_assign_control
>>>>>
>>>>> $cat /sys/fs/resctrl/info/L3_MON/mbm_assign_control
>>>>> //00=lt;01=lt
>>>>> /mon_a/00=t;01=t
>>>>> /ctrl_a/00=l;01=l
>>>>> ctrl_a/mon_ab/00=_;01=_
>>>>
>>>> The use case I'm interested in is iterating 32 counters over 256
>>>> groups[1]. If it's not possible to reassign 32 counters in a single
>>>> write system call, with just one IPI per domain per batch reassignment
>>>> operation, then I don't see any advantage over the original proposal
>>>> with the assignment control file in every group directory. We already
>>>> had fine-grained control placing assign/unassign nodes throughout the
>>>> directory hierarchy, with the scope implicit in the directory
>>>> location.
>>>
>>> The intent of this interface is to support modification of several
>>> groups with a single write. These examples only show impact to a single
>>> group at a time, but multiple groups can be modified by separating
>>> configurations with a "\n". I believe Babu was planning to add some
>>> of these examples in his next iteration since it is not obvious yet.
>>>
>>>>
>>>> The interface I proposed in [1] aims to reduce the per-domain IPIs by
>>>> a factor of the number of counters, rather than sending off 2 rounds
>>>> of IPIs to each domain for each monitoring group.
>>>
>>> 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 changes
>>> 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=_\nc2/m2/00=_\n'
>
>>
>> write([mbm_assign_control fd],
>> "/c1/m1/00=_;02=_;03=_;04=_;05=_;06=_;07=_;08=_;09=_;10=_;11=_;12=_;13=_;14=_;15=_\n"
>> "/c1/m2/00=_;01=_;02=_;03=_;04=_;05=_;06=_;07=_;08=_;09=_;10=_;11=_;12=_;13=_;14=_;15=_\n"
>> "/c1/m3/00=_;01=_;02=_;03=_;04=_;05=_;06=_;07=_;08=_;09=_;10=_;11=_;12=_;13=_;14=_;15=_\n"
>> [...]
>> "/c1/m14/00=_;01=_;02=_;03=_;04=_;05=_;06=_;07=_;08=_;09=_;10=_;11=_;12=_;13=_;14=_;15=_\n"
>> "/c1/m15/00=_;01=_;02=_;03=_;04=_;05=_;06=_;07=_;08=_;09=_;10=_;11=_;12=_;13=_;14=_;15=_\n"
>> "/c1/m16/00=lt;01=lt;02=lt;03=lt;04=lt;05=lt;06=lt;07=lt;08=lt;09=lt;10=lt;11=lt;12=lt;13=lt;14=lt;15=lt\n"
>> "/c1/m17/00=lt;01=lt;02=lt;03=lt;04=lt;05=lt;06=lt;07=lt;08=lt;09=lt;10=lt;11=lt;12=lt;13=lt;14=lt;15=lt\n"
>> "/c1/m18/00=lt;01=lt;02=lt;03=lt;04=lt;05=lt;06=lt;07=lt;08=lt;09=lt;10=lt;11=lt;12=lt;13=lt;14=lt;15=lt\n"
>> [...]
>> "/c1/m30/00=lt;01=lt;02=lt;03=lt;04=lt;05=lt;06=lt;07=lt;08=lt;09=lt;10=lt;11=lt;12=lt;13=lt;14=lt;15=lt\n"
>> "/c1/m31/00=lt;01=lt;02=lt;03=lt;04=lt;05=lt;06=lt;07=lt;08=lt;09=lt;10=lt;11=lt;12=lt;13=lt;14=lt;15=lt\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"?
Yea. Sound good to me. Will let you know if there are any troubles when I
start working on it.
I am also thinking about replacing the newline requirement for multiple
groups. Domains separate by "," and groups separate by ";".
Something like this..
"/c1/m1/00=_,01=_;/c1/m2/00=_,01=_;/c1/m3/00=lt,01=lt"
Thoughts?
> So, your example could possibly also be accomplished with a
>
> c1/m1/=_\nc1/m2/=_\nc1/m3/=_\n [...] c1/m16/=lt\nc1/m17/=lt\nc1/m18/=_\n [...]
>
> Any thoughts?
>
> Reinette
--
Thanks
Babu Moger
next prev parent reply other threads:[~2024-03-08 3:50 UTC|newest]
Thread overview: 145+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 0:57 [PATCH 00/15] x86/resctrl : Support AMD QoS RMID Pinning feature Babu Moger
2023-12-01 0:57 ` [PATCH 01/15] x86/resctrl: Remove hard-coded memory bandwidth limit Babu Moger
2023-12-05 23:18 ` Reinette Chatre
2023-12-06 16:29 ` Moger, Babu
2023-12-06 17:09 ` Reinette Chatre
2023-12-06 17:37 ` Moger, Babu
2023-12-01 0:57 ` [PATCH 02/15] x86/resctrl: Remove hard-coded memory bandwidth event configuration Babu Moger
2023-12-05 23:21 ` Reinette Chatre
2023-12-06 17:17 ` Moger, Babu
2023-12-06 18:32 ` Reinette Chatre
2023-12-06 19:17 ` Moger, Babu
2023-12-07 19:02 ` Reinette Chatre
2023-12-07 23:37 ` Moger, Babu
2023-12-01 0:57 ` [PATCH 03/15] x86/resctrl: Add support for Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2023-12-01 0:57 ` [PATCH 04/15] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2023-12-01 0:57 ` [PATCH 05/15] x86/resctrl: Detect ABMC feature details Babu Moger
2023-12-01 0:57 ` [PATCH 06/15] x86/resctrl: Add the mount option for ABMC feature Babu Moger
2023-12-01 0:57 ` [PATCH 07/15] x86/resctrl: Add support to enable/disable " Babu Moger
2023-12-05 16:48 ` kernel test robot
2023-12-05 17:40 ` Moger, Babu
2023-12-05 18:50 ` kernel test robot
2023-12-01 0:57 ` [PATCH 08/15] x86/resctrl: Introduce interface to display number of ABMC counters Babu Moger
2023-12-01 0:57 ` [PATCH 09/15] x86/resctrl: Add interface to display monitor state of the group Babu Moger
2023-12-01 0:57 ` [PATCH 10/15] x86/resctrl: Initialize ABMC counters bitmap Babu Moger
2023-12-01 0:57 ` [PATCH 11/15] x86/resctrl: Add data structures for ABMC assignment Babu Moger
2023-12-01 0:57 ` [PATCH 12/15] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg Babu Moger
2023-12-01 0:57 ` [PATCH 13/15] x86/resctrl: Add the interface to assign a ABMC counter Babu Moger
2023-12-01 0:57 ` [PATCH 14/15] x86/resctrl: Add interface unassign " Babu Moger
2023-12-05 17:55 ` kernel test robot
2023-12-05 18:09 ` Moger, Babu
2023-12-01 0:57 ` [PATCH 15/15] x86/resctrl: Update ABMC assignment on event configuration changes Babu Moger
2023-12-05 0:13 ` [PATCH 00/15] x86/resctrl : Support AMD QoS RMID Pinning feature Peter Newman
2023-12-05 23:17 ` Reinette Chatre
2023-12-06 15:40 ` Moger, Babu
2023-12-06 18:49 ` Reinette Chatre
2023-12-07 16:12 ` Moger, Babu
2023-12-07 19:29 ` Reinette Chatre
2023-12-07 23:07 ` Moger, Babu
2023-12-07 23:26 ` Reinette Chatre
2023-12-07 23:34 ` Moger, Babu
2023-12-08 22:58 ` Moger, Babu
2023-12-08 19:45 ` Peter Newman
2023-12-08 20:09 ` Reinette Chatre
2023-12-12 18:02 ` [PATCH v2 1/2] x86/resctrl: Remove hard-coded memory bandwidth limit Babu Moger
2023-12-15 2:20 ` Reinette Chatre
2024-01-02 19:52 ` Moger, Babu
2023-12-12 18:02 ` [PATCH v2 2/2] x86/resctrl: Remove hard-coded memory bandwidth event configuration Babu Moger
2023-12-15 1:24 ` Reinette Chatre
2024-01-02 20:00 ` Moger, Babu
2024-01-03 18:38 ` Reinette Chatre
2024-01-03 21:03 ` Moger, Babu
2024-01-03 21:40 ` Reinette Chatre
2024-01-04 13:48 ` Moger, Babu
2024-01-04 21:21 ` [PATCH v3 1/2] x86/resctrl: Remove hard-coded memory bandwidth limit Babu Moger
2024-01-05 21:14 ` Reinette Chatre
2024-01-05 23:51 ` Moger, Babu
2024-01-04 21:21 ` [PATCH v3 2/2] x86/resctrl: Remove hard-coded memory bandwidth event configuration Babu Moger
2024-01-05 21:18 ` Reinette Chatre
2024-01-06 0:13 ` Moger, Babu
2024-01-11 21:36 ` [PATCH v4 1/2] x86/resctrl: Remove hard-coded memory bandwidth limit Babu Moger
2024-01-11 21:36 ` [PATCH v4 2/2] x86/resctrl: Read supported bandwidth sources using CPUID command Babu Moger
2024-01-12 19:02 ` Reinette Chatre
2024-01-12 20:38 ` Moger, Babu
2024-01-12 21:24 ` Reinette Chatre
2024-01-12 21:54 ` Moger, Babu
2024-01-15 22:52 ` [PATCH v5 1/2] x86/resctrl: Remove hard-coded memory bandwidth limit Babu Moger
2024-01-23 10:36 ` Borislav Petkov
2024-01-23 14:58 ` Moger, Babu
2024-01-15 22:52 ` [PATCH v5 2/2] x86/resctrl: Read supported bandwidth sources using CPUID command Babu Moger
2024-01-16 19:44 ` Reinette Chatre
2024-01-16 21:39 ` Moger, Babu
2024-01-19 18:22 ` [PATCH v2 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-01-19 18:22 ` [PATCH v2 01/17] x86/cpufeatures: Add word 21 for scattered CPUID features Babu Moger
2024-01-19 18:22 ` [PATCH v2 02/17] x86/resctrl: Add support for Assignable Bandwidth Monitoring Counters (ABMC) Babu Moger
2024-01-19 18:22 ` [PATCH v2 03/17] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-01-19 18:22 ` [PATCH v2 04/17] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-02-20 17:56 ` James Morse
2024-02-20 21:27 ` Moger, Babu
2024-01-19 18:22 ` [PATCH v2 05/17] x86/resctrl: Introduce resctrl_file_fflags_init Babu Moger
2024-01-19 18:22 ` [PATCH v2 06/17] x86/resctrl: Introduce interface to display number of ABMC counters Babu Moger
2024-02-20 18:14 ` James Morse
2024-02-20 21:23 ` Moger, Babu
2024-01-19 18:22 ` [PATCH v2 07/17] x86/resctrl: Add support to enable/disable ABMC feature Babu Moger
2024-01-19 18:22 ` [PATCH v2 08/17] x86/resctrl: Introduce the interface to display ABMC state Babu Moger
2024-01-19 18:22 ` [PATCH v2 09/17] x86/resctrl: Introdruce rdtgroup_assign_enable_write Babu Moger
2024-01-19 18:22 ` [PATCH v2 10/17] x86/resctrl: Add interface to display monitor state of the group Babu Moger
2024-01-19 18:22 ` [PATCH v2 11/17] x86/resctrl: Report Unsupported when MBM events are read Babu Moger
2024-01-19 18:22 ` [PATCH v2 12/17] x86/resctrl: Initialize assignable counters bitmap Babu Moger
2024-01-19 18:22 ` [PATCH v2 13/17] x86/resctrl: Add data structures for ABMC assignment Babu Moger
2024-01-19 18:22 ` [PATCH v2 14/17] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg Babu Moger
2024-01-19 18:22 ` [PATCH v2 15/17] x86/resctrl: Add the interface to assign the RMID Babu Moger
2024-01-19 18:22 ` [PATCH v2 16/17] x86/resctrl: Add the interface unassign " Babu Moger
2024-01-19 18:22 ` [PATCH v2 17/17] x86/resctrl: Update RMID assignments on event configuration changes Babu Moger
2024-01-19 18:32 ` [PATCH v2 00/17] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Reinette Chatre
2024-01-19 20:35 ` Moger, Babu
2024-02-02 4:09 ` Reinette Chatre
2024-02-02 5:01 ` Reinette Chatre
2024-02-02 21:57 ` Moger, Babu
2024-02-05 22:38 ` Reinette Chatre
2024-02-08 17:29 ` Moger, Babu
2024-02-16 20:18 ` Peter Newman
2024-02-19 18:00 ` Moger, Babu
2024-02-20 15:21 ` James Morse
2024-02-20 18:11 ` Peter Newman
2024-02-23 21:47 ` Moger, Babu
2024-02-20 15:21 ` James Morse
2024-02-20 18:14 ` James Morse
2024-02-20 20:48 ` Moger, Babu
2024-02-23 17:17 ` Reinette Chatre
2024-02-23 20:11 ` Moger, Babu
2024-02-23 22:21 ` Reinette Chatre
2024-02-26 17:59 ` Moger, Babu
2024-02-26 21:20 ` Reinette Chatre
2024-02-27 18:12 ` Moger, Babu
2024-02-27 18:26 ` Peter Newman
2024-02-27 19:37 ` Moger, Babu
2024-02-27 20:06 ` Peter Newman
2024-02-27 20:42 ` Moger, Babu
2024-02-27 23:50 ` Reinette Chatre
2024-02-28 17:59 ` Moger, Babu
2024-02-28 20:04 ` Reinette Chatre
2024-02-29 20:37 ` Moger, Babu
2024-02-29 21:50 ` Reinette Chatre
2024-03-01 20:36 ` Moger, Babu
2024-03-01 23:20 ` Reinette Chatre
2024-03-04 19:34 ` Moger, Babu
2024-03-04 19:58 ` Reinette Chatre
2024-03-04 22:24 ` Moger, Babu
2024-03-05 14:58 ` Moger, Babu
2024-03-05 17:12 ` Reinette Chatre
2024-03-05 19:35 ` Moger, Babu
2024-03-07 18:57 ` Peter Newman
2024-03-07 20:41 ` Reinette Chatre
2024-03-07 22:33 ` Peter Newman
2024-03-07 22:53 ` Reinette Chatre
2024-03-07 23:14 ` Peter Newman
2024-03-08 17:13 ` Reinette Chatre
2024-03-08 3:50 ` Moger, Babu [this message]
2024-03-08 17:20 ` Reinette Chatre
2024-03-12 13:30 ` Moger, Babu
2024-03-11 15:40 ` Moger, Babu
2024-03-12 15:13 ` Reinette Chatre
2024-03-12 17:07 ` Moger, Babu
2024-03-12 17:15 ` Reinette Chatre
2024-03-12 17:24 ` Moger, Babu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46065d68-8334-4b76-bc68-c2695e7b98de@amd.com \
--to=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=james.morse@arm.com \
--cc=jithu.joseph@intel.com \
--cc=jmattson@google.com \
--cc=jpoimboe@kernel.org \
--cc=kai.huang@intel.com \
--cc=kan.liang@linux.intel.com \
--cc=kim.phillips@amd.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peternewman@google.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=reinette.chatre@intel.com \
--cc=rick.p.edgecombe@intel.com \
--cc=sandipan.das@amd.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=yanjiewtw@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).