Received-SPF: pass (google.com: domain of linux-kernel+bounces-177992-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <f49931b0-d9bf-45f0-ab35-93b1a78f6b97@intel.com>
Date: Mon, 13 May 2024 11:53:17 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v17 7/9] x86/resctrl: Add new monitor files for Sub-NUMA
 cluster (SNC) monitoring
To: Tony Luck <tony.luck@intel.com>
CC: Fenghua Yu <fenghua.yu@intel.com>, Maciej Wieczor-Retman
	<maciej.wieczor-retman@intel.com>, Peter Newman <peternewman@google.com>,
	James Morse <james.morse@arm.com>, Babu Moger <babu.moger@amd.com>, "Drew
 Fustini" <dfustini@baylibre.com>, Dave Martin <Dave.Martin@arm.com>,
	<x86@kernel.org>, <linux-kernel@vger.kernel.org>, <patches@lists.linux.dev>
References: <20240503203325.21512-1-tony.luck@intel.com>
 <20240503203325.21512-8-tony.luck@intel.com>
 <0178e84e-d55f-47bf-b8b0-58e05fcaa108@intel.com>
 <ZkJIZdU2knEUJN7Q@agluck-desk3>
Content-Language: en-US
From: Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <ZkJIZdU2knEUJN7Q@agluck-desk3>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?M3FlQzJ3ek9XYVltSHdmb3BtQTZyNVArN29BL1BvVXJpR3dQUG9raTZ1N2Jn?=
 =?utf-8?B?aHl2Uktqb2pudUw1S1BtbEh0Y3lsNndRd2pJRTM3ajRVSHpQcGZQZm83WUVT?=
 =?utf-8?B?N09Md0NYNnZ2L0hESGFWUi9lRDFHczgzTWZpRnRJWXE5WTVMdDlPWUFuazhP?=
 =?utf-8?B?aE5zaTB5N2hMSG1vRFlFK0JqbmZWNG9PM2pXUFl2YmcxWTcwN29jV2FlU0RX?=
 =?utf-8?B?SEFwb0YvNnRCbDVPUXlQb3RlVHlIZ29aNWJBZFhFNlR5L0djK2FnNHBBTGRJ?=
 =?utf-8?B?WHQ5MnZ3WVYyRlpteVhNeGphdUNwNFRLR0xBRUc0a0dTamtFZ0oxNFcySldt?=
 =?utf-8?B?NGUraUxvSDlxOTNxNm0ydnVGUWhWMzFrWnhZTEZuYVUrTGdIWkJmcWwzbHhm?=
 =?utf-8?B?TFo4VWZVdUNYM1UwTXJ0NUlDZGluclVKdlQ0ZFljNlBJZWdJTW9iSm5ZL0VR?=
 =?utf-8?B?M2JNZmR2QXk5MlRqMWZERkt5Mko5bnBVSm9aMnk0dUQyVjFQajRrdTVYYWU3?=
 =?utf-8?B?SVdYYUhlNmJXK09RcDRvTTEwNEJ6SndnVk1kdkdscC9WazJJUUVjd2hmMVBx?=
 =?utf-8?B?cU5xL2xjaVA2a3VkcFk1aVlRNEVJT0ZlWjBMNzVMc3Bzd052QkJyTDNtVUFD?=
 =?utf-8?B?NVhKZUFVUDFWS0hUUTJBMGhtMVdVSnVzZHIrZHl3Ynd3MlVnKzRxMlJQcUgx?=
 =?utf-8?B?b3VLRG1XUXZQS2RJYXBES1lSQTJrbURDODQvVTMydVlSb2tEMDMvWEFKYUwv?=
 =?utf-8?B?L0hTNXl0czU2cEhxOVgzVXR3Z203cVJwR2VWdFF6My9Vb3d4d2ZrbGpueUZE?=
 =?utf-8?B?K1lGa2lQMVBsVUtndzB1czF3V1FQb1VEY2p1QWRXUkhjOEtSMWJHNG5CVnlz?=
 =?utf-8?B?RXg0NFRvckVtcDg4TTBWVndiblA2U0d2akNUSEd4SU9zSVk0Mmc3Q0JsalBG?=
 =?utf-8?B?OERxRnV1eVY3WVBmRW5yLzlUbm56bklNbzBTY2g2cXgwb1FqRFpLdEZBdVRj?=
 =?utf-8?B?eDNIbnpIbEtBMlIzVEMwTnVQREVRT1hUV1YzdmJxWmwwOVBsdUF3V2loNXkr?=
 =?utf-8?B?NGxXd2xSK3ZycVYrVDBuWmRwMmJ3dzRDNFo2cHNZQnBnVThKb0pKYm5qeldV?=
 =?utf-8?B?TU5YQVVxWS9CTnErTXZjdWVibVZNcTVUTjJwTDRncEdrV1V0QWNscTBhU1ZD?=
 =?utf-8?B?NkFSeG9rd0pzSkdJWHd1K1dqNVNYdHdOaFdvbVZ6RmY1bk5wU1NFVlVoMHFH?=
 =?utf-8?B?ZXE3bFYxeGZGN1RlOVYxaW9tQWdRb0NUUnovR3dEb25vWFZ6Z1dBRDR2NFlS?=
 =?utf-8?B?OC95Z3NkSis5NnAzbjRsdENHMDl4S1JaZGVXVXNtZEZxS1E0ekdNSklFTW9Z?=
 =?utf-8?B?bFJjbHB0dnVscWZKUWJZVDFGMDdYaFE4a252bnE2aXZsckgvUkg2UzFIRTdj?=
 =?utf-8?B?WVBNS0JxcUNLVmpDMlpDSTgwTVp6SzRhUHVuT2xrVWxNS3BHeWorR2IyNDlM?=
 =?utf-8?B?Y3VNYXJHQ1BCeWFoa1ZhSVUvQ2tYcDM5MzBxL0F1VmZOV214RWlVQmUwVUlR?=
 =?utf-8?B?bTJadWtJZ1U1OWdPa29hMDg3TVdDN0NsSVJBUzRPb2ZIOXFzNEtLcGo2SVMx?=
 =?utf-8?B?T3hWbHR5UTQxR2pIRFZ6N0ZESHlla2Q3T1BLT09uaTNiRE1aTXFPbUV5U3ha?=
 =?utf-8?B?MWl6Y3VnNERjWnJ1ZFR0QVlHbUtxVU53OXhzWjQ0WTdiZTA0Y2c1WkRnQXdY?=
 =?utf-8?B?ZEJxd0pkLzB2YUVRTnlwaTB0ZmpFL0pFWjlJaUp3cnNya0pKZkM0VnphTkRZ?=
 =?utf-8?B?UU1mVXdaTk5uUkRnNTJ3QzFuV1dBdkt5Y2EyUktvaHNFVTR1YkhRWVJmTzJL?=
 =?utf-8?B?a2VpZFFvRGpja3dBL0lRVG1NTGFTcWdyZk1MQkoyRlVocFNJSGYwTlJzeDBM?=
 =?utf-8?B?RGdWQ1VWYUxDWlI5b2NPYjdML1kyNUg3eHRGbG14dFZpVkp0YkhVS1lyeFJH?=
 =?utf-8?B?aGlvYXlPSWd3bXhnSHgyU21VNlNrcVF3OC9GN296MStTV2lpVWQ5U2xISUF0?=
 =?utf-8?B?TGFzU0E2VDVyOXY2TzMzbGlSR1hSRzlPbzFLTS9zUTI4MnA5eHc0TEZ0bnlR?=
 =?utf-8?B?OVhUa2xtTUVjb2RSeE5KWkY4RXZIelVmR0d1K3JrYTBQaGJ2WHMyKzJjRy9z?=
 =?utf-8?B?T1E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ca8d373-a9ff-49cc-5531-08dc737df4e4
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2024 18:53:19.9620
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Ub7ZTwMf3uhkuDDnxl8HjeDDZD3QgcHUEer9XmROlDfPsU3sulqRdHRkd8c5tl4NbfaKRu0QVNXvCnAf1eTBWEzYT9qaTrkmbM4egi9oPB8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7372
X-OriginatorOrg: intel.com

Hi Tony,

On 5/13/2024 10:05 AM, Tony Luck wrote:
> On Fri, May 10, 2024 at 02:24:13PM -0700, Reinette Chatre wrote:
>> Hi Tony,
> 
> Hi Reinette,
> 
> Thanks for the review. Detailed comments below. But overall I'm
> going to split patch 7 into a bunch of smaller changes, each with
> a better commit message.
> 
>> On 5/3/2024 1:33 PM, Tony Luck wrote:
>>
>> (Could you please start the changelog with some context?)
>>
>>> Add a field to the rdt_resource structure to track whether monitoring
>>> resources are tracked by hardware at a different scope (NODE) from
>>> the legacy L3 scope.
>>
>> This seems to describe @mon_scope that was introduced in patch #3?
> 
> Not really. Patch #3 made the change so that control an monitor
> functions can have different scope. That's still needed as with SNC
> enabled the underlying data collection is at the node level for
> monitoring, while control stays at the L3 cache scope.
> 
> This new field describes the legacy scope of monitoring, so that
> resctrl can provide correctly scoped monitor files for legacy
> applications that aren't aware of SNC. So I'm using this both
> to indicate when SNC is enabled (with mon_scope != mon_display_scope)
> or disabled (when they are the same).

This seems to enforce the idea that these new additions aim to be
generic on the surface but the only goal is to support SNC.

> 
>>>
>>> Add a field to the rdt_mon_domain structure to track the L3 cache id
>>> which can be used to find all the domains that need resource counts
>>> summed to provide accurate values in the legacy monitoring files.
>>
>> Why is this field necessary? Can this not be obtained dynamically?
> 
> I could compute it each time I need it (when making/removing
> directories, or finding which SNC domains share an L3 domain).
> 
> 	id = get_domain_id_from_scope(cpumask_any(&d->cpu_mask), r->mon_display_scope);
> 	if (id < 0)
> 		// error path
> 
> But it seemed better to just discover this once at domain creation time.

This may be more clear in the next version?

..

>>>  	/*
>>>  	 * As per the SDM, when IA32_QM_EVTSEL.EvtID (bits 7:0) is configured
>>>  	 * with a valid event code for supported resource type and the bits
>>> @@ -207,7 +198,7 @@ static int __rmid_read(u32 rmid, enum resctrl_event_id eventid, u64 *val)
>>>  	 * IA32_QM_CTR.Error (bit 63) and IA32_QM_CTR.Unavailable (bit 62)
>>>  	 * are error bits.
>>>  	 */
>>> -	wrmsr(MSR_IA32_QM_EVTSEL, eventid, rmid + rmid_offset);
>>> +	wrmsr(MSR_IA32_QM_EVTSEL, eventid, rmid);
>>>  	rdmsrl(MSR_IA32_QM_CTR, msr_val);
>>>  
>>>  	if (msr_val & RMID_VAL_ERROR)
>>> @@ -291,7 +282,7 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d,
>>>  
>>>  	resctrl_arch_rmid_read_context_check();
>>>  
>>> -	if (!cpumask_test_cpu(smp_processor_id(), &d->hdr.cpu_mask))
>>> +	if (d->display_id != get_cpu_cacheinfo_id(smp_processor_id(), r->mon_display_scope))
>>>  		return -EINVAL;
>>
>> Does this mean that when SNC is enabled then reading data for an event within a particular
>> monitor domain ("node scope") can read its data from any CPU within the L3 domain
>> ("mon_display_scope") even if that CPU is not associated with the node for which it
>> is reading the data?
> 
> Yes.
> 
>> If so this really turns many resctrl assumptions and architecture on its head since the
>> resctrl expectation is that only CPUs within a domain's cpumask can be used to interact
>> with the domain. This in turn makes this seemingly general feature actually SNC specific.
> 
> This is only an expectation for x86 features using IA32_QM_EVTSEL/IA32_QM_CTR
> MSR method to read counters. ARM doesn't have the "CPU must be in
> domain" restriction (as far as I can tell). Nor does the Intel IO RDT
> (which uses MMIO space for control registers, these can be read/written
> from any CPU).
> 
> We do know that those two MSRs can be read from any CPU that shares an
> L3 cache. It would seem to be pointless overhead to force a cross
> processor interrupt to read them from a different CPU just to satisfy
> a "must be in same domain" non-requirement. I'l split this into its
> own patch with suitable description.

I did not suggest that this should be done with multiple IPIs. My comment
was related to this addition that claims to be generic but really just focuses
on support for SNC. Any  future addition that may want to build on this would
need to be aware of these expectations, which are not obvious at this time.

..

 
>>>  	return 0;
>>>  }
>>>  
>>> +static u32 get_node_rmid(struct rdt_resource *r, struct rdt_mon_domain *d, u32 rmid)
>>> +{
>>> +	int cpu = cpumask_any(&d->hdr.cpu_mask);
>>> +
>>> +	return rmid + (cpu_to_node(cpu) % snc_nodes_per_l3_cache) * r->num_rmid;
>>> +}
>>> +
>>> +static int __mon_event_count(u32 closid, u32 rmid, struct rmid_read *rr)
>>> +{
>>> +	struct rdt_mon_domain *d;
>>> +	struct rmid_read tmp;
>>> +	u32 node_rmid;
>>> +	int ret = 0;
>>> +
>>> +	if (!rr->sumdomains) {
>>> +		node_rmid = get_node_rmid(rr->r, rr->d, rmid);
>>> +		return ___mon_event_count(closid, node_rmid, rr, &rr->val);
>>> +	}
>>> +
>>> +	tmp = *rr;
>>> +	list_for_each_entry(d, &rr->r->mon_domains, hdr.list) {
>>> +		if (d->display_id == rr->d->display_id) {
>>> +			tmp.d = d;
>>> +			node_rmid = get_node_rmid(rr->r, d, rmid);
>>> +			ret = ___mon_event_count(closid, node_rmid, &tmp, &rr->val);
>>
>> If I understand correctly this function is run per IPI on a CPU associated
>> with one of the monitor domains (depends on which one came online first),
>> and then it will read the monitor data of the other domains from the same
>> CPU? This is unexpected since the expectation is that monitor data
>> needs to be read from a CPU associated with the domain it is
>> reading data for.
> 
> See earlier note. The counter can be read from any CPU sharing the same
> L3. Adding unnecessary IPI is pointless overhead. But I will add
> comments.

I did not suggest to add extra IPIs, my comment was related to how this
feature wedges itself into resctrl.

> 
>> Also, providing tmp as well as rr->val seems unnecessary?
> 
> I think I was unsure about modifying the domain field in the struct
> rmid_read in the middle of the call chain. But the original caller
> mon_event_read() doesn't look at rr->domain after the smp_call*()
> function returns. I will drop "tmp".
> 
>>> +			if (ret)
>>> +				break;
>>> +		}
>>> +	}
>>> +
>>> +	return ret;
>>> +}
>>> +
>>>  /*
>>>   * mbm_bw_count() - Update bw count from values previously read by
>>>   *		    __mon_event_count().
>>> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> index 0923492a8bd0..a56ae08ca255 100644
>>> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
>>> @@ -3011,57 +3011,118 @@ static int mon_addfile(struct kernfs_node *parent_kn, const char *name,
>>>   * and monitor groups with given domain id.
>>>   */
>>>  static void rmdir_mondata_subdir_allrdtgrp(struct rdt_resource *r,
>>> -					   unsigned int dom_id)
>>> +					   struct rdt_mon_domain *d)
>>>  {
>>>  	struct rdtgroup *prgrp, *crgrp;
>>> +	struct rdt_mon_domain *dom;
>>> +	bool remove_all = true;
>>> +	struct kernfs_node *kn;
>>> +	char subname[32];
>>>  	char name[32];
>>>  
>>> +	sprintf(name, "mon_%s_%02d", r->name, d->display_id);
>>> +	if (r->mon_scope != r->mon_display_scope) {
>>> +		int count = 0;
>>> +
>>> +		list_for_each_entry(dom, &r->mon_domains, hdr.list)
>>> +			if (d->display_id == dom->display_id)
>>> +				count++;
>>> +		if (count > 1) {
>>> +			remove_all = false;
>>> +			sprintf(subname, "mon_sub_%s_%02d", r->name, d->hdr.id);
>>> +		}
>>> +	}
>>
>>
>> This seems awkward. I wonder if it may not be simpler to just
>> remove the directory and on completion check if the parent has
>> any subdirectories left and remove the parent if there are no
>> subdirectories remaining. Something possible via reading the inode's
>> i_nlink that is accessible via kernfs_get_inode(). What do you think?
> 
> kernfs_get_inode() needs a pointer to the "struct super_block" for the
> filesystem. Resctrl filesystem code doesn't seem to keep track of that
> anywhere. Only mentioned in rdt_kill_sb() where core kernfs code passes
> it in as the argument. When registering/mounting the resctrl filesystem
> there's a "struct fs_context *fc" ... is there a function to get the
> super block from that? Even if there is, I'd need to add a global to
> save a copy of the fc_context.

hmmm ... I expected that struct file or struct dentry may be reachable
from where sb can be obtained but I can only see that now for the
paths that provide struct kernfs_open_file.


..

>
>>>  	}
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int mkdir_mondata_subdir(struct kernfs_node *parent_kn,
>>> +				struct rdt_mon_domain *d,
>>> +				struct rdt_resource *r, struct rdtgroup *prgrp)
>>> +{
>>> +	struct kernfs_node *kn, *ckn;
>>> +	char name[32];
>>> +	bool do_sum;
>>> +	int ret;
>>> +
>>> +	do_sum = r->mon_scope != r->mon_display_scope;
>>> +	sprintf(name, "mon_%s_%02d", r->name, d->display_id);
>>> +	kn = kernfs_find_and_get_ns(parent_kn, name, NULL);
>>> +	if (!kn) {
>>> +		/* create the directory */
>>> +		kn = kernfs_create_dir(parent_kn, name, parent_kn->mode, prgrp);
>>> +		if (IS_ERR(kn))
>>> +			return PTR_ERR(kn);
>>> +
>>> +		ret = rdtgroup_kn_set_ugid(kn);
>>> +		if (ret)
>>> +			goto out_destroy;
>>> +		ret = mon_add_all_files(kn, d, r, prgrp, do_sum);
>>
>> This does not look right. If I understand correctly the private data
>> of these event files will have whichever mon domain came up first as
>> its domain id. That seems completely arbitrary and does not reflect
>> accurate state for this file. Since "do_sum" is essentially a "flag"
>> on how this file can be treated, can its "dom_id" not rather be
>> the "monitor scope domain id"? Could that not help to eliminate 
>> that per-domain "display_id"?
> 
> You are correct that this should be the "monitor scope domain id" rather
> than the first SNC domain that appears. I'll change to use that. I don't
> think it helps in removing the per-domain display_id.

Wouldn't the file metadata then be the "display_id"?

Reinette