mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
	corbet@lwn.net, fenghua.yu@intel.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com
Cc: 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, peternewman@google.com,
	maciej.wieczor-retman@intel.com, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, eranian@google.com,
	james.morse@arm.com
Subject: Re: [PATCH v5 00/20] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC)
Date: Wed, 17 Jul 2024 12:19:17 -0500	[thread overview]
Message-ID: <1c50b589-a738-4ae6-8362-bd1ce0d0dc98@amd.com> (raw)
In-Reply-To: <e04b721a-b5cb-4089-a3ad-125a6247e5b8@intel.com>

Hi Reinette,

On 7/12/24 17:03, Reinette Chatre wrote:
> Hi Babu,
> 
> On 7/3/24 2:48 PM, Babu Moger wrote:
>> # Linux Implementation
>>
>> Linux resctrl subsystem provides the interface to count maximum of two
>> memory bandwidth events per group, from a combination of available total
>> and local events. Keeping the current interface, users can enable a maximum
>> of 2 ABMC counters per group. User will also have the option to enable only
>> one counter to the group. If the system runs out of assignable ABMC
>> counters, kernel will display an error. Users need to disable an already
>> enabled counter to make space for new assignments.
> 
> The implementation appears to be converging on an interface that can
> be generic enough to be used by other features discussed along the way.
> "Linux implementation" summary can thus add:
> 
>     Create a generic interface aimed to support user space assignment
>     of scarce counters used for monitoring. First usage of interface
>     is by ABMC with option to expand usage to "soft-RMID" and MPAM
>     counters in future.

Sure.

> 
> 
>> # Examples
>>
>> a. Check if ABMC support is available
>>     #mount -t resctrl resctrl /sys/fs/resctrl/
>>
>>     #cat /sys/fs/resctrl/info/L3_MON/mbm_mode
>>     [abmc]
>>     legacy
>>
>>     Linux kernel detected ABMC feature and it is enabled.
> 
> How about renaming "abmc" to "mbm_cntrs"? This will match the num_mbm_cntrs
> info file and be the final step to make this generic so that another
> architecture
> can more easily support assignining hardware counters without needing to call
> the feature AMD's "abmc".

I think we aleady settled this with "mbm_cntr_assignable".

For soft-RMID" it will be mbm_sw_assignable.


> 
> Expanding on this it may be possible to add a new "sw_mbm_cntrs" feature that
> will be the "soft-RMID" feature while also reflecting the "mbm_cntrs" name
> so that when user space enables that feature its properties can be found in
> "num_mbm_cntrs".
> 
> The "abmc" kernel parameter remains but that does seem separate from this
> resctrl fs feature since it is explicitly tied to X86_FEATURE_ABMC surely
> making it architecture specific.
> 
>>
>> b. Check how many ABMC counters are available.
>>
>>     #cat /sys/fs/resctrl/info/L3_MON/num_cntrs
>>     32
> 
> This is now num_mbm_cntrs

Sure.

> 
>>
>> c. Create few resctrl groups.
>>
>>     # mkdir /sys/fs/resctrl/mon_groups/child_default_mon_grp
>>     # mkdir /sys/fs/resctrl/non_default_ctrl_mon_grp
>>     # mkdir
>> /sys/fs/resctrl/non_default_ctrl_mon_grp/mon_groups/child_non_default_mon_grp
>>
>>
>> d. This series adds a new interface file
>> /sys/fs/resctrl/info/L3_MON/mbm_control
>>     to list and modify the group's monitoring states. File provides
>> single place
>>     to list monitoring states of all the resctrl groups. It makes it
>> easier for
>>     user space to learn about the counters are used without needing to
>> traverse
>>     all the groups thus reducing the number of filesystem calls.
>>
>>     The list follows the following format:
>>
>>     "<CTRL_MON group>/<MON group>/<domain_id>=<flags>"
>>
>>     Format for specific type of groups:
>>
>>     * Default CTRL_MON group:
>>      "//<domain_id>=<flags>"
>>
>>         * Non-default CTRL_MON group:
>>                 "<CTRL_MON group>//<domain_id>=<flags>"
>>
>>         * Child MON group of default CTRL_MON group:
>>                 "/<MON group>/<domain_id>=<flags>"
>>
>>         * Child MON group of non-default CTRL_MON group:
>>                 "<CTRL_MON group>/<MON group>/<domain_id>=<flags>"
>>
>>         Flags can be one of the following:
>>
>>          t  MBM total event is enabled.
>>          l  MBM local event is enabled.
>>          tl Both total and local MBM events are enabled.
>>          _  None of the MBM events are enabled
> 
> The language needs to be changed here (and in the many copied places) to
> be specific about what setting the flag accomplishes. For example, in
> "legacy" mode user space can be expected to find all events enabled, no?
> Needing a new feature to set a flag to accomplish something that is
> possible in legacy mode can thus cause confusion.

Yes. It is possible to do it. But I feel unnessassary.

> 
> If I understand the implementation reading "mbm_control" will fail
> if system is ABMC capable but it is disabled. Why can "mbm_control" not
> always be displayed to user space? For example, what if "mbm_control" is
> always available to user space and it can provide specific information to
> user space. For example:
>     t  MBM total event is enabled but may not always be counted.
>     T  MBM total event is enabled and being counted.
> 
> On AMD systems resource groups will have "t" associated with monitor
> groups when ABMC disabled, "T" when ABMC enabled and a counter assigned.
> On Intel systems monitor groups will always have "T".

I think more flags will add more confusion.

> 
> For "soft-RMID" the flag could possible continue to be "T"?
> 
> I am trying to find ways to communicate to user space consistently
> and clearly and any insights will be appreciated. We really do not want
> to add this interface and then find that it just causes confusion.
> 
> It is not quite obvious to me when the new files should be visible and
> what they should present to the user. "mbm_mode" is now always visible.
> Should "num_mbm_cntrs" not also always be visible? Right now "num_mbm_cntrs"
> appears to be only associated to ABMC, should it not also, for example,
> be the file that "soft-RMID" may use to share how many counters are
> available? Its contents will thus be dynamic based on which "MBM mode" is
> active, begging the question, what should it contain when "legacy" mode is
> enabled, should "num_mbm_cntrs" perhaps show "0" to user space when
> "legacy" mode is active?

Its good we have this discussion.

How about we go with simple way for now. The mbm_mode will only available
when ABMC or Soft_RMID(MPAM feature) is supported. Same way for the
num_mbm_cntrs.


> 
>>
>>     Examples:
>>
>>     # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>>     non_default_ctrl_mon_grp//0=tl;1=tl;
>>     non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>>     //0=tl;1=tl;
>>     /child_default_mon_grp/0=tl;1=tl;
>>     
>>     There are four groups and all the groups have local and total
>>     event enabled on domain 0 and 1.
> 
> "local and total event" is vague, can it be made specific with, for example,
> "local and total MBM events"

Sure.

> 
>>
>>     =tl means both total and local events are enabled.
> 
> Same here (and all copied places in this series)

Sure.

> 
>>
>>     "//" - This is a default CTRL_MON group
>>
>>     "non_default_ctrl_mon_grp//" - This is non-default CTRL_MON group
>>
>>     "/child_default_mon_grp/"  - This is Child MON group of the defult
>> group
> 
> Same typos as in previous version of cover letter.

Oh. no. Will fix it.

> 
>>
>>     "non_default_ctrl_mon_grp/child_non_default_mon_grp/" - This is child
>>     MON group of the non-default group
>>
>> e. Update the group assignment states using the interface file
>> /sys/fs/resctrl/info/L3_MON/mbm_control.
>>
>>     The write format is similar to the above list format with addition of
>>     op-code for the assignment operation.
>>     
>>     * Default CTRL_MON group:
>>             "//<domain_id><op-code><flags>"
>>     
>>     * Non-default CTRL_MON group:
>>             "<CTRL_MON group>//<domain_id><op-code><flags>"
>>     
>>     * Child MON group of default CTRL_MON group:
>>             "/<MON group>/<domain_id><op-code><flags>"
>>     
>>     * Child MON group of non-default CTRL_MON group:
>>             "<CTRL_MON group>/<MON group>/<domain_id><op-code><flags>"
>>     
>>     Op-code can be one of the following:
>>     
>>     = Update the assignment to match the flag.
>>     + Assign a new state.
>>     - Unassign a new state.
> 
> Please be consistent with terminology. Above switches between "flag"
> and "state" while it then continues below using "event". Also,
> "Unassign a _new_ state" is unexpected, it should probably be an
> _existing_ (not "new") state/flag/event?

I will use event consistantly.

> 
>>
>>     Flags can be one of the following:
>>
>>          t  MBM total event.
>>          l  MBM local event.
>>          tl Both total and local MBM events.
>>          _  None of the MBM events. Only works with '=' op-code.
>>     
>>     Initial group status:
>>     # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>>     non_default_ctrl_mon_grp//0=tl;1=tl;
>>     non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>>     //0=tl;1=tl;
>>     /child_default_mon_grp/0=tl;1=tl;
>>
>>     To update the default group to enable only total event on domain 0:
>>     # echo "//0=t" > /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>>     Assignment status after the update:
>>     # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>>     non_default_ctrl_mon_grp//0=tl;1=tl;
>>     non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>>     //0=t;1=tl;
>>     /child_default_mon_grp/0=tl;1=tl;
>>
>>     To update the MON group child_default_mon_grp to remove total event
>> on domain 1:
>>     # echo "/child_default_mon_grp/1-t" >
>> /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>>     Assignment status after the update:
>>     $ cat /sys/fs/resctrl/info/L3_MON/mbm_control
>>     non_default_ctrl_mon_grp//0=tl;1=tl;
>>     non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=tl;
>>     //0=t;1=tl;
>>     /child_default_mon_grp/0=tl;1=l;
>>
>>     To update the MON group
>> non_default_ctrl_mon_grp/child_non_default_mon_grp to
>>     remove both local and total events on domain 1:
>>     # echo "non_default_ctrl_mon_grp/child_non_default_mon_grp/1=_" >
>>            /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>>     Assignment status after the update:
>>     non_default_ctrl_mon_grp//0=tl;1=tl;
>>     non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=_;
>>     //0=t;1=tl;
>>     /child_default_mon_grp/0=tl;1=l;
>>
>>     To update the default group to add a local event domain 0.
>>     # echo "//0+l" > /sys/fs/resctrl/info/L3_MON/mbm_control
>>
>>     Assignment status after the update:
>>     # cat /sys/fs/resctrl/info/L3_MON/mbm_control
>>     non_default_ctrl_mon_grp//0=tl;1=tl;
>>     non_default_ctrl_mon_grp/child_non_default_mon_grp/0=tl;1=_;
>>     //0=tl;1=tl;
>>     /child_default_mon_grp/0=tl;1=l;
>>
>>
>> f. Read the event mbm_total_bytes and mbm_local_bytes of the default group.
>>     There is no change in reading the events with ABMC. If the event is
>> unassigned
>>     when reading, then the read will come back as "Unassigned".
>>     
>>     # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
>>     779247936
>>     # cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_local_bytes
>>     765207488
>>     
>> g. Users will have the option to go back to legacy mbm_mode if required.
>>     This can be done using the following command. Note that switching the
>>     mbm_mode will reset all the mbm counters of all resctrl groups.
> 
> mbm -> MBM (throughout)

Sure.

> 
>>
>>     # echo "legacy" > /sys/fs/resctrl/info/L3_MON/mbm_mode
>>     # cat /sys/fs/resctrl/info/L3_MON/mbm_mode
>>     abmc
>>     [legacy]
>>
>> h. Check the bandwidth configuration for the group. Note that bandwidth
>>     configuration has a domain scope. Total event defaults to 0x7F (to
>>     count all the events) and local event defaults to 0x15 (to count all
>>     the local numa events). The event bitmap decoding is available at
>>     https://www.kernel.org/doc/Documentation/x86/resctrl.rst
>>     in section "mbm_total_bytes_config", "mbm_local_bytes_config":
>>     
>>     #cat /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
>>     0=0x7f;1=0x7f
>>     
>>     #cat /sys/fs/resctrl/info/L3_MON/mbm_local_bytes_config
>>     0=0x15;1=0x15
>>     
>> j. Change the bandwidth source for domain 0 for the total event to count
>> only reads.
>>     Note that this change effects total events on the domain 0.
>>     
>>     #echo 0=0x33 > /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
>>     #cat /sys/fs/resctrl/info/L3_MON/mbm_total_bytes_config
>>     0=0x33;1=0x7F
>>     
>> k. Now read the total event again. The first read will come back with
>> "Unavailable"
>>     status. The subsequent read of mbm_total_bytes will display only the
>> read events.
>>     
>>     #cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
>>     Unavailable
>>     #cat /sys/fs/resctrl/mon_data/mon_L3_00/mbm_total_bytes
>>     314101
>>     
>> l. Unmount the resctrl
>>     
>>     #umount /sys/fs/resctrl/
>>
> 
> Reinette
> 

-- 
Thanks
Babu Moger

  reply	other threads:[~2024-07-17 17:19 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03 21:48 Babu Moger
2024-07-03 21:48 ` [PATCH v5 01/20] x86/cpufeatures: Add support for " Babu Moger
2024-07-12 21:55   ` Reinette Chatre
2024-07-15 18:36     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 02/20] x86/resctrl: Add ABMC feature in the command line options Babu Moger
2024-07-03 21:48 ` [PATCH v5 03/20] x86/resctrl: Consolidate monitoring related data from rdt_resource Babu Moger
2024-07-12 21:57   ` Reinette Chatre
2024-07-15 19:05     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 04/20] x86/resctrl: Detect Assignable Bandwidth Monitoring feature details Babu Moger
2024-07-12 22:04   ` Reinette Chatre
2024-07-15 20:04     ` Moger, Babu
2024-07-16 15:11       ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 05/20] x86/resctrl: Introduce resctrl_file_fflags_init() to initialize fflags Babu Moger
2024-07-12 22:04   ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 06/20] x86/resctrl: Add support to enable/disable AMD ABMC feature Babu Moger
2024-07-12 22:05   ` Reinette Chatre
2024-07-16 15:13     ` Moger, Babu
2024-07-16 17:51       ` Reinette Chatre
2024-07-16 18:48         ` Moger, Babu
2024-07-16 20:41           ` Reinette Chatre
2024-07-18 21:11         ` Moger, Babu
2024-08-16 16:29     ` James Morse
2024-07-03 21:48 ` [PATCH v5 07/20] x86/resctrl: Introduce the interface to display monitor mode Babu Moger
2024-07-12 22:06   ` Reinette Chatre
2024-07-16 16:51     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 08/20] x86/resctrl: Introduce interface to display number of monitoring counters Babu Moger
2024-07-03 21:48 ` [PATCH v5 09/20] x86/resctrl: Initialize monitor counters bitmap Babu Moger
2024-07-12 22:07   ` Reinette Chatre
2024-07-16 17:59     ` Moger, Babu
2024-07-26 22:48   ` Peter Newman
2024-07-26 23:53     ` Moger, Babu
2024-08-01 21:05     ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 10/20] x86/resctrl: Introduce mbm_total_cfg and mbm_local_cfg Babu Moger
2024-07-12 22:08   ` Reinette Chatre
2024-07-16 19:21     ` Moger, Babu
2024-07-16 20:42       ` Reinette Chatre
2024-07-16 22:43         ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 11/20] x86/resctrl: Remove MSR reading of event configuration value Babu Moger
2024-07-12 22:10   ` Reinette Chatre
2024-07-16 19:34     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 12/20] x86/resctrl: Add data structures and definitions for ABMC assignment Babu Moger
2024-07-12 22:13   ` Reinette Chatre
2024-07-16 20:24     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 13/20] x86/resctrl: Add the interface to assign hardware counter Babu Moger
2024-07-12 22:09   ` Reinette Chatre
2024-07-16 20:45     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 14/20] x86/resctrl: Add the interface to unassign " Babu Moger
2024-07-03 21:48 ` [PATCH v5 15/20] x86/resctrl: Assign/unassign counters by default when ABMC is enabled Babu Moger
2024-07-12 22:10   ` Reinette Chatre
2024-07-16 20:58     ` Moger, Babu
2024-07-26 23:22   ` Peter Newman
2024-07-26 23:57     ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 16/20] x86/resctrl: Report "Unassigned" for MBM events in ABMC mode Babu Moger
2024-07-12 22:13   ` Reinette Chatre
2024-07-16 21:04     ` Moger, Babu
2024-07-13 20:26   ` Markus Elfring
2024-07-03 21:48 ` [PATCH v5 17/20] x86/resctrl: Introduce the interface switch between monitor modes Babu Moger
2024-07-12 22:14   ` Reinette Chatre
2024-07-16 22:46     ` Moger, Babu
2024-07-13  7:15   ` Markus Elfring
2024-07-03 21:48 ` [PATCH v5 18/20] x86/resctrl: Enable AMD ABMC feature by default when supported Babu Moger
2024-07-12 22:15   ` Reinette Chatre
2024-07-16 23:23     ` Moger, Babu
2024-07-26  0:16       ` Moger, Babu
2024-08-01 21:40         ` Reinette Chatre
2024-07-03 21:48 ` [PATCH v5 19/20] x86/resctrl: Introduce interface to list monitor states of all the groups Babu Moger
2024-07-12 22:16   ` Reinette Chatre
2024-07-17 15:22     ` Moger, Babu
2024-08-01 21:37       ` Reinette Chatre
2024-08-02 16:10         ` Moger, Babu
2024-07-03 21:48 ` [PATCH v5 20/20] x86/resctrl: Introduce interface to modify assignment states of " Babu Moger
2024-07-12 22:17   ` Reinette Chatre
2024-07-17 16:22     ` Moger, Babu
2024-07-25  0:03   ` Peter Newman
2024-07-25  1:22     ` Moger, Babu
2024-07-25 17:11       ` Peter Newman
2024-07-25 17:28         ` Moger, Babu
2024-08-01 18:56           ` Reinette Chatre
2024-08-01 19:40             ` Moger, Babu
2024-07-12 22:03 ` [PATCH v5 00/20] x86/resctrl : Support AMD Assignable Bandwidth Monitoring Counters (ABMC) Reinette Chatre
2024-07-17 17:19   ` Moger, Babu [this message]
2024-08-01 21:49     ` Reinette Chatre
2024-08-01 22:45       ` Peter Newman
2024-08-02 16:13         ` Reinette Chatre
2024-08-02 18:49           ` Moger, Babu
2024-08-02 19:13             ` Peter Newman
2024-08-02 20:23               ` Moger, Babu
2024-08-02 18:49           ` Peter Newman
2024-08-02 20:38             ` Moger, Babu
2024-08-02 20:55             ` Reinette Chatre
2024-08-02 22:50               ` Peter Newman
2024-08-14 17:37                 ` Reinette Chatre
2024-08-15 23:06                   ` Peter Newman
2024-08-16  1:45                     ` Reinette Chatre
2024-08-03  0:49               ` 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=1c50b589-a738-4ae6-8362-bd1ce0d0dc98@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

all inboxes | Powered by JetHome®