mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Babu Moger <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
	"Moger, Babu" <bmoger@amd.com>, Tony Luck <tony.luck@intel.com>,
	Ben Horgan <ben.horgan@arm.com>,
	James Morse <james.morse@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Drew Fustini <fustini@kernel.org>,
	Fenghua Yu <fenghuay@nvidia.com>, Chen Yu <yu.c.chen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Peter Newman <peternewman@google.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] mpam,x86,fs/resctrl: Generic schema description Proof of Concept
Date: Wed, 17 Jun 2026 15:29:02 -0500	[thread overview]
Message-ID: <430ffb48-29f4-44d9-9164-9f8b743b2739@amd.com> (raw)
In-Reply-To: <d503393b-0fea-4c39-9e0d-96b5ffdc624d@intel.com>

Hi Reinette,

On 6/17/26 12:18, Reinette Chatre wrote:
> Hi Babu,
> 
> On 6/15/26 2:05 PM, Moger, Babu wrote:
>>
>> Re-based GMBA patches[3] on top of this series.
> 
> Thank you very much for trying it out.
> 
>>
>> [3] https://lore.kernel.org/lkml/cover.1776980182.git.babu.moger@amd.com/
>>
>> #sudo mount -t resctrl resctrl /sys/fs/resctrl
>>
>> #cat /sys/fs/resctrl/schemata
>> SMBA_GBL:0=4096;1=4096
>>       SMBA:0=8192;1=8192;2=8192;3=8192
>>     MB_GBL:0=4096;1=4096
>>         MB:0=8192;1=8192;2=8192;3=8192
>>         L3:0=ffff;1=ffff;2=ffff;3=ffff
>>
>>
>> Needed this change to get the schemata alignment correctly.
>>
>> Note: Renamed GMB to MB_GBL and GSMBA to SMBA_GBL.
>>
>> ===========================================================
>> diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
>> index 979176b054e8..6123689e1250 100644
>> --- a/fs/resctrl/ctrlmondata.c
>> +++ b/fs/resctrl/ctrlmondata.c
>> @@ -512,17 +512,22 @@ static void show_doms(struct seq_file *s, struct rdt_resource_final *f,
>>   {
>>          struct rdt_resource *r = f->res;
>>          struct rdt_ctrl_domain *dom;
>> +       char res_name[16];
>>          bool sep = false;
>>          u32 ctrl_val;
>>
>>          /* Walking r->domains, ensure it can't race with cpuhp */
>>          lockdep_assert_cpus_held();
>>
>> -       if (print_ctrl)
>> -               seq_printf(s, "%*s%s%s:", max_name_width, f->name,
>> -                               resctrl_ctrl_is_default(ctrl) ? "" : "_",
>> -                               resctrl_ctrl_is_default(ctrl) ?
>> -                                "" : resctrl_ctrl_name_str(ctrl->name));
>> +       if (print_ctrl) {
>> +               if (resctrl_ctrl_is_default(ctrl))
>> +                       snprintf(res_name, sizeof(res_name), "%s", f->name);
>> +               else
>> +                       snprintf(res_name, sizeof(res_name), "%s_%s",
>> +                                       f->name, resctrl_ctrl_name_str(ctrl->name));
>> +               seq_printf(s, "%*s:", max_name_width, res_name);
>> +       }
>> +
>>          list_for_each_entry(dom, &ctrl->domains, hdr.list) {
>>                  if (sep)
>>                          seq_puts(s, ";");
>>
> 
> This looks like a workaround for a bug. Are you perhaps running with Tony's
> fixup included?
> https://lore.kernel.org/lkml/aiB2oJFPF-sqUVQx@agluck-desk3/

Ah.. I missed that.

> 
>> ====================================================================
>>
>> $ tree /sys/fs/resctrl/info/MB/
>> /sys/fs/resctrl/info/MB/
>> ├── bandwidth_gran
>> ├── delay_linear
>> ├── min_bandwidth
>> ├── num_closids
>> └── resource_schemata
>>      ├── MB
>>      │   ├── max
>>      │   ├── min
>>      │   ├── resolution
>>      │   ├── scale
>>      │   ├── scope
>>      │   ├── tolerance
>>      │   ├── type
>>      │   └── unit
>>      └── MB_GBL
>>          ├── max
>>          ├── min
>>          ├── resolution
>>          ├── scale
>>          ├── scope
>>          ├── tolerance
>>          ├── type
>>          └── unit
>>
>> 4 directories, 20 files
>>
>>
>> $ tree /sys/fs/resctrl/info/SMBA/
>> /sys/fs/resctrl/info/SMBA/
>> ├── bandwidth_gran
>> ├── delay_linear
>> ├── min_bandwidth
>> ├── num_closids
>> └── resource_schemata
>>      ├── SMBA
>>      │   ├── max
>>      │   ├── min
>>      │   ├── resolution
>>      │   ├── scale
>>      │   ├── scope
>>      │   ├── tolerance
>>      │   ├── type
>>      │   └── unit
>>      └── SMBA_GBL
>>          ├── max
>>          ├── min
>>          ├── resolution
>>          ├── scale
>>          ├── scope
>>          ├── tolerance
>>          ├── type
>>          └── unit
>>
>> 4 directories, 20 files
>>
>> Does the info directory hierarchy look right?
> 
> I am not sure if the "GBL" extension is most informative. In this thread there
> were some motivations for the control names to include the scope. It could be useful
> to create some control naming customs to not have the schemata file become chaotic.

Make sense.

> Apart from that the hierarchy above matches what we have so far for the new schema
> descriptions.
> 
> Could you please also share the contents of the new files resulting from this
> implementation?

Used this script to print:

$tree -fi info/MB | while read f; do
     if [ -f "$f" ]; then
         printf "%s: %s\n" "$f" "$(cat "$f")"
     else
         echo "$f"
     fi
done


info/MB
info/MB/bandwidth_gran: 1
info/MB/delay_linear: 0
info/MB/min_bandwidth: 0
info/MB/num_closids: 16
info/MB/resource_schemata
info/MB/resource_schemata/MB
info/MB/resource_schemata/MB/max: 8192
info/MB/resource_schemata/MB/min: 0
info/MB/resource_schemata/MB/resolution: 8
info/MB/resource_schemata/MB/scale: 1
info/MB/resource_schemata/MB/scope: L3
info/MB/resource_schemata/MB/tolerance: 0
info/MB/resource_schemata/MB/type: scalar
info/MB/resource_schemata/MB/unit: GBps
info/MB/resource_schemata/MB_GBL
info/MB/resource_schemata/MB_GBL/max: 4096
info/MB/resource_schemata/MB_GBL/min: 0
info/MB/resource_schemata/MB_GBL/resolution: 1
info/MB/resource_schemata/MB_GBL/scale: 1
info/MB/resource_schemata/MB_GBL/scope: Unsupported control scope
info/MB/resource_schemata/MB_GBL/tolerance: 0
info/MB/resource_schemata/MB_GBL/type: scalar
info/MB/resource_schemata/MB_GBL/unit: GBps

4 directories, 20 files


info/SMBA
info/SMBA/bandwidth_gran: 1
info/SMBA/delay_linear: 0
info/SMBA/min_bandwidth: 0
info/SMBA/num_closids: 16
info/SMBA/resource_schemata
info/SMBA/resource_schemata/SMBA
info/SMBA/resource_schemata/SMBA/max: 8192
info/SMBA/resource_schemata/SMBA/min: 0
info/SMBA/resource_schemata/SMBA/resolution: 8
info/SMBA/resource_schemata/SMBA/scale: 1
info/SMBA/resource_schemata/SMBA/scope: L3
info/SMBA/resource_schemata/SMBA/tolerance: 0
info/SMBA/resource_schemata/SMBA/type: scalar
info/SMBA/resource_schemata/SMBA/unit: GBps
info/SMBA/resource_schemata/SMBA_GBL
info/SMBA/resource_schemata/SMBA_GBL/max: 4096
info/SMBA/resource_schemata/SMBA_GBL/min: 0
info/SMBA/resource_schemata/SMBA_GBL/resolution: 1
info/SMBA/resource_schemata/SMBA_GBL/scale: 1
info/SMBA/resource_schemata/SMBA_GBL/scope: Unsupported control scope
info/SMBA/resource_schemata/SMBA_GBL/tolerance: 0
info/SMBA/resource_schemata/SMBA_GBL/type: scalar
info/SMBA/resource_schemata/SMBA_GBL/unit: GBps

4 directories, 20 files


> 
>> After going through the comments, it seems like it should cover most
>> of the upcoming features. At least the Global MBA/SMBA stuff looks
>> like it fits in well with the RFC.
> 
> That is good news.
> 
>> What is your expectation for the RFC going forward?
> 
> The "opens" of the RFC needs to be finalized as well as the items identified during this
> discussion. How to support emulated controls looks to be the biggest one. While the
> initial schema description may not need to support emulated controls, how to support
> it needs to be clear since the initial schema description needs to be accompanied
> with enough user documentation to support such future change.
> 
> It should be possible to start upstreaming at least the preparatory patches.
> 

Sounds good. Will keep an eye out for it.
Thanks
Babu


  reply	other threads:[~2026-06-17 20:29 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29 18:06 Reinette Chatre
2026-06-02 20:23 ` Babu Moger
2026-06-02 22:56   ` Reinette Chatre
2026-06-03  1:14     ` Moger, Babu
2026-06-03  3:55       ` Reinette Chatre
2026-06-03 14:40         ` Babu Moger
2026-06-02 23:32 ` Chen, Yu C
2026-06-03  3:45   ` Reinette Chatre
2026-06-03 11:53     ` Chen, Yu C
2026-06-04 16:37       ` Reinette Chatre
2026-06-05 15:43         ` Chen, Yu C
2026-06-05 16:20           ` Reinette Chatre
2026-06-03 15:15 ` Ben Horgan
2026-06-03 19:34   ` Drew Fustini
2026-06-04 11:24     ` Ben Horgan
2026-06-04 17:38       ` Drew Fustini
2026-06-12  1:30         ` Shaopeng Tan (Fujitsu)
2026-06-17 15:29           ` Reinette Chatre
2026-06-19  1:42             ` Shaopeng Tan (Fujitsu)
2026-06-22 16:10               ` Reinette Chatre
2026-06-23  5:04                 ` Shaopeng Tan (Fujitsu)
2026-06-04 21:05     ` Reinette Chatre
2026-06-05 19:35       ` Drew Fustini
2026-06-06  5:10         ` Drew Fustini
2026-06-06  5:23           ` Drew Fustini
2026-06-04 17:43   ` Reinette Chatre
2026-06-05 14:53     ` Ben Horgan
2026-06-05 15:39       ` Reinette Chatre
2026-06-05 16:37         ` Ben Horgan
2026-06-08 16:16           ` Reinette Chatre
2026-06-09 10:10             ` Ben Horgan
2026-06-09 15:28               ` Reinette Chatre
2026-06-09 16:37                 ` Ben Horgan
2026-06-09 17:41                   ` Reinette Chatre
2026-06-10  7:09                     ` Chen, Yu C
2026-06-10 14:27                       ` Chen, Yu C
2026-06-10 16:13                         ` Reinette Chatre
2026-06-10 17:57                           ` Chen, Yu C
2026-06-10 18:10                             ` Reinette Chatre
2026-06-10 15:59                       ` Reinette Chatre
2026-06-10 18:05                         ` Chen, Yu C
2026-06-11  3:26                         ` Chen, Yu C
2026-06-11 15:45                           ` Reinette Chatre
2026-06-26 15:46                             ` Chen, Yu C
2026-07-02 14:27                               ` Ben Horgan
2026-07-03  9:01                                 ` Chen, Yu C
2026-07-14 21:37                               ` Reinette Chatre
2026-07-15  2:49                                 ` Chen, Yu C
2026-06-10  4:31                 ` Drew Fustini
2026-06-10 15:14                   ` Reinette Chatre
2026-06-03 18:46 ` Luck, Tony
2026-06-04 10:02   ` Ben Horgan
2026-06-04 21:42   ` Reinette Chatre
2026-07-08 12:56     ` Chen, Yu C
2026-07-14 21:39       ` Reinette Chatre
2026-06-03 22:14 ` Drew Fustini
2026-06-04 21:47   ` Reinette Chatre
2026-06-05 19:48     ` Drew Fustini
2026-06-15 21:05 ` Moger, Babu
2026-06-17 17:18   ` Reinette Chatre
2026-06-17 20:29     ` Babu Moger [this message]
2026-06-24 19:08 ` Fenghua Yu
2026-06-24 22:22   ` Reinette Chatre
2026-06-25  1:26     ` Fenghua Yu
2026-06-25 15:43       ` Reinette Chatre
2026-07-10 20:59         ` Fenghua Yu
2026-07-14 22:06           ` Reinette Chatre
2026-07-15  8:34             ` Ben Horgan
2026-07-15 15:41               ` Reinette Chatre
2026-07-16 14:59                 ` Ben Horgan
2026-07-16 16:02                   ` Luck, Tony
2026-07-16 16:22                     ` Ben Horgan
2026-07-16 17:50                       ` Reinette Chatre
2026-07-17 10:27                         ` Ben Horgan
2026-07-16 16:04                   ` Reinette Chatre
2026-07-16 16:44                     ` Ben Horgan
2026-07-16 17:07                       ` Reinette Chatre
2026-07-17 12:20                         ` Ben Horgan
2026-07-17 16:00                           ` Reinette Chatre
2026-07-17 16:02                     ` Chen, Yu C
2026-07-17 16:55                       ` Reinette Chatre
2026-07-02 13:37       ` Ben Horgan
2026-07-02 15:16         ` Fenghua Yu
2026-07-03 13:42           ` Ben Horgan

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=430ffb48-29f4-44d9-9164-9f8b743b2739@amd.com \
    --to=babu.moger@amd.com \
    --cc=Dave.Martin@arm.com \
    --cc=ben.horgan@arm.com \
    --cc=bmoger@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghuay@nvidia.com \
    --cc=fustini@kernel.org \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peternewman@google.com \
    --cc=reinette.chatre@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=yu.c.chen@intel.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