All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chen, Yu C" <yu.c.chen@intel.com>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
	<tglx@kernel.org>, <bp@alien8.de>, <mingo@redhat.com>,
	<dave.hansen@linux.intel.com>, <hpa@zytor.com>,
	<dave.martin@arm.com>, <james.morse@arm.com>,
	<fenghuay@nvidia.com>, <babu.moger@amd.com>,
	<anil.keshavamurthy@broadcom.com>, <tony.luck@intel.com>,
	Chen Yu <yu.c.chen@intel.com>
Subject: Re: [PATCH v4 6/6] x86/resctrl: Add support for L3 occupancy monitoring via RMID MMIO read
Date: Mon, 22 Jun 2026 22:09:48 +0800	[thread overview]
Message-ID: <04f67dbd-43ed-4863-a51f-cf75e9a02e55@intel.com> (raw)
In-Reply-To: <ec8650d4-71fb-468c-8adb-f1fe94eda813@intel.com>

Hi Reinette,

On 6/19/2026 7:40 AM, Reinette Chatre wrote:
> Hi Chenyu,
> 
> On 6/13/26 12:57 AM, Chen Yu wrote:
>> The CMRC (Cache Monitoring Registers for CPU Agents Description)
>> ACPI sub-table provides the MMIO address used to read the LLC
>> occupancy counter for each RMID. When ERDT is enabled on the
>> platform, use this MMIO interface instead of the legacy MSR read
>> to obtain the L3 occupancy value.
>>
>> Introduce erdt_mon_read(), a helper that retrieves monitoring
>> data for a given RMID and event ID from an ERDT domain. Initial
>> support is added for the L3 occupancy monitoring event
>> (QOS_L3_OCCUP_EVENT_ID).
>>
>> If the platform supports ERDT, CMRC-based MMIO access is used by
>> default. If ERDT is unavailable, the implementation is to use
>> MSR-based operations.
> 
> (nit: please write in imperative tone and use entire line length available)
> 
> ...
> 

OK, will do in next version.

>> diff --git a/arch/x86/include/asm/resctrl.h b/arch/x86/include/asm/resctrl.h
>> index 97c2f6bc7a5f..9b3b03279dd8 100644
>> --- a/arch/x86/include/asm/resctrl.h
>> +++ b/arch/x86/include/asm/resctrl.h
>> @@ -41,6 +41,8 @@ struct resctrl_pqr_state {
>>   };
>>   
>>   bool erdt_enabled(void);
>> +struct rdt_domain_hdr;
>> +int erdt_mon_read(struct rdt_domain_hdr *hdr, int ev_id, int rmid, u64 *val);
>>   
>>   DECLARE_PER_CPU(struct resctrl_pqr_state, pqr_state);
>>   
>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
>> index 90730f0851fa..fe812f7190fc 100644
>> --- a/arch/x86/kernel/cpu/resctrl/core.c
>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
>> @@ -965,7 +965,7 @@ static __init bool get_rdt_mon_resources(void)
>>   	bool ret = false;
>>   
>>   	if (rdt_cpu_has(X86_FEATURE_CQM_OCCUP_LLC)) {
>> -		resctrl_enable_mon_event(QOS_L3_OCCUP_EVENT_ID, false, 0, NULL);
>> +		resctrl_enable_mon_event(QOS_L3_OCCUP_EVENT_ID, erdt_enabled(), 0, NULL);
>>   		ret = true;
>>   	}
>>   	if (rdt_cpu_has(X86_FEATURE_CQM_MBM_TOTAL)) {
> 
> As mentioned in patch #1, when erdt_enabled() is true the enumeration still proceeds to
> enumerate the monitoring properties via CPUID to discover the number of RMIDs that the
> *MSR* supports and use it as the maximum RMID (and thus the maximum number of registers)
> that MMIO supports?
> 

OK, will switch to the maximum RMID exposed by ACPI table, if 
erdt_enabled() is true.

>> diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c
>> index 9209927f88a2..1491f96b57c3 100644
>> --- a/arch/x86/kernel/cpu/resctrl/monitor.c
>> +++ b/arch/x86/kernel/cpu/resctrl/monitor.c
>> @@ -278,6 +278,13 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain_hdr *hdr,
>>   
>>   	switch (r->rid) {
>>   	case RDT_RESOURCE_L3:
>> +		/*
>> +		 * No SNC for mmio based L3 occupancy, so there is no need
> 
> "No SNC for mmio based L3 occupancy" is too significant to be buried like this. Could you
> please elaborate on this claim and enforce it with the implementation? For example,
> could rdt_get_l3_mon_config() WARN and *not* set r->mon_capable if erdt_enable() and
> snc_nodes_per_l3_cache > 1?
> 

IIUC, SNC happens to be unsupported on platforms that currently support 
MMIO-based
access. I’m not sure if there will be a platform that enables both MMIO 
access and
SNC. I’ll add a WARN here as suggested (and handle the case if such 
platform is
introduced later).

thanks,
Chenyu

>> +		 * to convert logical RMID to a physical RMID via
>> +		 * logical_rmid_to_physical_rmid().
>> +		 */
>> +		if (erdt_enabled() && eventid == QOS_L3_OCCUP_EVENT_ID)
>> +			return erdt_mon_read(hdr, eventid, rmid, val);
>>   		return arch_l3_read_event(hdr, rmid, eventid, val, r);
>>   	case RDT_RESOURCE_PERF_PKG:
>>   		return intel_aet_read_event(hdr->id, rmid, arch_priv, val);
> 
> Reinette

  reply	other threads:[~2026-06-22 14:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-13  7:56 [PATCH v4 0/6] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
2026-06-13  7:56 ` [PATCH v4 1/6] x86/resctrl: Parse ACPI ERDT table and map RMDD domains by L3 cache ID Chen Yu
2026-06-18 23:37   ` Reinette Chatre
2026-06-22  9:07     ` Chen, Yu C
2026-06-22 21:28       ` Reinette Chatre
2026-06-23  6:29         ` Chen, Yu C
2026-06-23 11:43           ` Chen, Yu C
2026-06-23 16:46             ` Reinette Chatre
2026-06-24  4:05               ` Chen, Yu C
2026-06-13  7:57 ` [PATCH v4 2/6] x86/resctrl: Parse ACPI CMRC table Chen Yu
2026-06-13  7:57 ` [PATCH v4 3/6] x86/resctrl: Rename prev_msr to prev_mon_val Chen Yu
2026-06-18 23:39   ` Reinette Chatre
2026-06-22 12:42     ` Chen, Yu C
2026-06-22 21:29       ` Reinette Chatre
2026-06-23  7:48         ` Chen, Yu C
2026-06-23 16:47           ` Reinette Chatre
2026-06-13  7:57 ` [PATCH v4 4/6] x86/resctrl: Refactor the monitor read function Chen Yu
2026-06-13  7:57 ` [PATCH v4 5/6] fs/resctrl: Do not invoke smp_processor_id() in preemptible context Chen Yu
2026-06-13  7:57 ` [PATCH v4 6/6] x86/resctrl: Add support for L3 occupancy monitoring via RMID MMIO read Chen Yu
2026-06-18 23:40   ` Reinette Chatre
2026-06-22 14:09     ` Chen, Yu C [this message]
2026-06-22 21:30       ` Reinette Chatre
2026-06-23  5:00         ` Chen, Yu C
2026-06-23 16:48           ` Reinette Chatre

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=04f67dbd-43ed-4863-a51f-cf75e9a02e55@intel.com \
    --to=yu.c.chen@intel.com \
    --cc=anil.keshavamurthy@broadcom.com \
    --cc=babu.moger@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.martin@arm.com \
    --cc=fenghuay@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=reinette.chatre@intel.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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.