All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Moger, Babu" <babu.moger@amd.com>
To: Reinette Chatre <reinette.chatre@intel.com>,
	tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
	dave.hansen@linux.intel.com
Cc: x86@kernel.org, hpa@zytor.com, akpm@linux-foundation.org,
	paulmck@kernel.org, thuth@redhat.com, rostedt@goodmis.org,
	xiongwei.song@windriver.com, pawan.kumar.gupta@linux.intel.com,
	jpoimboe@kernel.org, daniel.sneddon@linux.intel.com,
	thomas.lendacky@amd.com, perry.yuan@amd.com,
	sandipan.das@amd.com, kai.huang@intel.com, seanjc@google.com,
	xin3.li@intel.com, ebiggers@google.com,
	andrew.cooper3@citrix.com, mario.limonciello@amd.com,
	tan.shaopeng@fujitsu.com, james.morse@arm.com,
	tony.luck@intel.com, peternewman@google.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	eranian@google.com, corbet@lwn.net
Subject: Re: [PATCH v3 6/7] x86/resctrl: Introduce interface to display io_alloc CBMs
Date: Mon, 7 Apr 2025 15:18:16 -0500	[thread overview]
Message-ID: <c4ec0e32-5c4e-4c83-bc9d-4bdfd3474ca8@amd.com> (raw)
In-Reply-To: <65124831-2c00-4ab7-91db-f8e348686d7d@intel.com>

Hi Reinette,

On 3/21/25 17:58, Reinette Chatre wrote:
> Hi Babu,
> 
> On 1/30/25 1:20 PM, Babu Moger wrote:
>> The io_alloc feature in resctrl enables system software to configure
>> the portion of the L3 cache allocated for I/O traffic.
>>
>> Add the interface to display CBMs (Capacity Bit Mask) of io_alloc
>> feature.
>>
>> When CDP is enabled, io_alloc routes traffic using the highest CLOSID
>> which corresponds to CDP_CODE. Add a check for the CDP resource type.
> 
> It is not obvious to me what is meant with "highest CLOSID
> which corresponds to CDP_CODE" ... how about "highest CLOSID used by
> a L3CODE resource"?

Yes. That is correct.


>>
>> Signed-off-by: Babu Moger <babu.moger@amd.com>
>> ---
>> v3: Minor changes due to changes in resctrl_arch_get_io_alloc_enabled()
>>     and resctrl_io_alloc_closid_get().
>>     Added the check to verify CDP resource type.
>>     Updated the commit log.
>>
>> v2: Fixed to display only on L3 resources.
>>     Added the locks while processing.
>>     Rename the displat to io_alloc_cbm (from sdciae_cmd).
>> ---
>>  arch/x86/kernel/cpu/resctrl/core.c        |  2 ++
>>  arch/x86/kernel/cpu/resctrl/ctrlmondata.c |  2 +-
>>  arch/x86/kernel/cpu/resctrl/internal.h    |  1 +
>>  arch/x86/kernel/cpu/resctrl/rdtgroup.c    | 38 +++++++++++++++++++++++
>>  4 files changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
>> index 88bc95c14ea8..030f738dea8d 100644
>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>> @@ -311,6 +311,8 @@ static void rdt_set_io_alloc_capable(struct rdt_resource *r)
>>  	r->cache.io_alloc_capable = true;
>>  	resctrl_file_fflags_init("io_alloc",
>>  				 RFTYPE_CTRL_INFO | RFTYPE_RES_CACHE);
>> +	resctrl_file_fflags_init("io_alloc_cbm",
>> +				 RFTYPE_CTRL_INFO | RFTYPE_RES_CACHE);
>>  }
>>  
>>  static void rdt_get_cdp_l3_config(void)
>> diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
>> index 536351159cc2..d272dea43924 100644
>> --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
>> +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
>> @@ -444,7 +444,7 @@ u32 resctrl_arch_get_config(struct rdt_resource *r, struct rdt_ctrl_domain *d,
>>  	return hw_dom->ctrl_val[idx];
>>  }
>>  
>> -static void show_doms(struct seq_file *s, struct resctrl_schema *schema, int closid)
>> +void show_doms(struct seq_file *s, struct resctrl_schema *schema, int closid)
>>  {
>>  	struct rdt_resource *r = schema->res;
>>  	struct rdt_ctrl_domain *dom;
>> diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/resctrl/internal.h
>> index 61bc609e932b..07cf8409174d 100644
>> --- a/arch/x86/kernel/cpu/resctrl/internal.h
>> +++ b/arch/x86/kernel/cpu/resctrl/internal.h
>> @@ -668,4 +668,5 @@ void resctrl_file_fflags_init(const char *config, unsigned long fflags);
>>  void rdt_staged_configs_clear(void);
>>  bool closid_allocated(unsigned int closid);
>>  int resctrl_find_cleanest_closid(void);
>> +void show_doms(struct seq_file *s, struct resctrl_schema *schema, int closid);
>>  #endif /* _ASM_X86_RESCTRL_INTERNAL_H */
>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> index 37295dd14abe..81b9d8c5dabf 100644
>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>> @@ -1967,6 +1967,38 @@ static ssize_t resctrl_io_alloc_write(struct kernfs_open_file *of, char *buf,
>>  	return ret ?: nbytes;
>>  }
>>  
>> +static int resctrl_io_alloc_cbm_show(struct kernfs_open_file *of,
>> +				     struct seq_file *seq, void *v)
>> +{
>> +	struct resctrl_schema *s = of->kn->parent->priv;
>> +	struct rdt_resource *r = s->res;
>> +	u32 io_alloc_closid;
>> +	int ret = 0;
>> +
>> +	if (!r->cache.io_alloc_capable || s->conf_type == CDP_DATA) {
>> +		rdt_last_cmd_puts("io_alloc feature is not supported on the resource\n");
> 
> rdt_last_cmd_puts() has to be called with rdtgroup_mutex held, also clear it before use.

Sure.

> 
>> +		return -EINVAL;
> 
> How about ENODEV?

Sure.

> 
>> +	}
>> +
>> +	cpus_read_lock();
>> +	mutex_lock(&rdtgroup_mutex);
>> +
>> +	if (!resctrl_arch_get_io_alloc_enabled(r)) {
>> +		rdt_last_cmd_puts("io_alloc feature is not enabled\n");
>> +		ret = -EINVAL;
>> +		goto cbm_show_out;
>> +	}
>> +
>> +	io_alloc_closid = resctrl_io_alloc_closid_get(r, s);
>> +
>> +	show_doms(seq, s, io_alloc_closid);
>> +
>> +cbm_show_out:
>> +	mutex_unlock(&rdtgroup_mutex);
>> +	cpus_read_unlock();
>> +	return ret;
>> +}
>> +
>>  /* rdtgroup information files for one cache resource. */
>>  static struct rftype res_common_files[] = {
>>  	{
>> @@ -2126,6 +2158,12 @@ static struct rftype res_common_files[] = {
>>  		.seq_show	= resctrl_io_alloc_show,
>>  		.write		= resctrl_io_alloc_write,
>>  	},
>> +	{
>> +		.name		= "io_alloc_cbm",
>> +		.mode		= 0444,
>> +		.kf_ops		= &rdtgroup_kf_single_ops,
>> +		.seq_show	= resctrl_io_alloc_cbm_show,
>> +	},
>>  	{
>>  		.name		= "mba_MBps_event",
>>  		.mode		= 0644,
> 
> Reinette
> 

-- 
Thanks
Babu Moger

  reply	other threads:[~2025-04-07 20:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-30 21:20 [PATCH v3 0/7] Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Babu Moger
2025-01-30 21:20 ` [PATCH v3 1/7] x86/cpufeatures: Add support for L3 Smart Data Cache Injection Allocation Enforcement Babu Moger
2025-01-30 21:20 ` [PATCH v3 2/7] x86/resctrl: Add SDCIAE feature in the command line options Babu Moger
2025-01-30 21:20 ` [PATCH v3 3/7] x86/resctrl: Detect io_alloc feature Babu Moger
2025-03-21 22:51   ` Reinette Chatre
2025-04-07 20:13     ` Moger, Babu
2025-01-30 21:20 ` [PATCH v3 4/7] x86/resctrl: Implement "io_alloc" enable/disable handlers Babu Moger
2025-03-21 22:53   ` Reinette Chatre
2025-04-07 20:14     ` Moger, Babu
2025-01-30 21:20 ` [PATCH v3 5/7] x86/resctrl: Add interface to enable/disable io_alloc feature Babu Moger
2025-03-21 22:58   ` Reinette Chatre
2025-04-07 20:17     ` Moger, Babu
2025-01-30 21:20 ` [PATCH v3 6/7] x86/resctrl: Introduce interface to display io_alloc CBMs Babu Moger
2025-03-21 22:58   ` Reinette Chatre
2025-04-07 20:18     ` Moger, Babu [this message]
2025-01-30 21:20 ` [PATCH v3 7/7] x86/resctrl: Introduce interface to modify io_alloc Capacity Bit Masks Babu Moger
2025-03-21 23:00   ` Reinette Chatre
2025-04-07 20:19     ` Moger, Babu
2025-03-21 22:50 ` [PATCH v3 0/7] Support L3 Smart Data Cache Injection Allocation Enforcement (SDCIAE) Reinette Chatre
2025-04-07 20:12   ` Moger, Babu
2025-04-08 21:44     ` Reinette Chatre
2025-04-09  0:41       ` Moger, Babu
2025-04-09  1:41         ` Reinette Chatre
2025-04-10  0:58           ` Moger, Babu
2025-04-10  3:59             ` Reinette Chatre
2025-04-10 22:29               ` 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=c4ec0e32-5c4e-4c83-bc9d-4bdfd3474ca8@amd.com \
    --to=babu.moger@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=daniel.sneddon@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebiggers@google.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=jpoimboe@kernel.org \
    --cc=kai.huang@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mingo@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=perry.yuan@amd.com \
    --cc=peternewman@google.com \
    --cc=reinette.chatre@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=sandipan.das@amd.com \
    --cc=seanjc@google.com \
    --cc=tan.shaopeng@fujitsu.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=thuth@redhat.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    --cc=xin3.li@intel.com \
    --cc=xiongwei.song@windriver.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.