Received-SPF: pass (google.com: domain of linux-kernel+bounces-195881-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <0e7dcfd4-a7a4-4205-b848-801540c28234@intel.com>
Date: Thu, 30 May 2024 13:23:59 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v19 14/20] x86/resctrl: Fill out rmid_read structure for
 smp_call*() to read a counter
To: Tony Luck <tony.luck@intel.com>, 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>
CC: <x86@kernel.org>, <linux-kernel@vger.kernel.org>,
	<patches@lists.linux.dev>
References: <20240528222006.58283-1-tony.luck@intel.com>
 <20240528222006.58283-15-tony.luck@intel.com>
Content-Language: en-US
From: Reinette Chatre <reinette.chatre@intel.com>
In-Reply-To: <20240528222006.58283-15-tony.luck@intel.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
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?SURLM0paZzYzRlFMYUxlNHZVQ2M1SE4weEZZcVNZWEdqdGpIVFpIS1RiSmEx?=
 =?utf-8?B?cVNLeklMQnE1SWY5V2dtNFJFay9XYlB6Z0RoR1lCYVBaN2VsYzArMGRLNUp5?=
 =?utf-8?B?M2lXUUVNdzAzRTBUbEtibVpmaGFTUTAydld2MW5xYmprLzFkYzhlVTVmWFJ0?=
 =?utf-8?B?SmZLaDJyVkV5S2k3bWhUTC96S2pwaDB1QUJwejkzWFN1VkVEazhyMGNpUm8x?=
 =?utf-8?B?Wi9LcnZ3WGsxR1hLOFJHY2xCY0QzL2RDOVgrMXRDZVVUS1V3M0p0cTEyRFkr?=
 =?utf-8?B?dVFPZmFwRzJ4NDNDSUROUTJSdktRdmtya21pN0ZkRHc0d2RyWWdpSzNLaFBx?=
 =?utf-8?B?ZEtMVFBsckxjUCtOTmExYlhyeTJSSVVBSlRpWXNReitodWZRNEp6ME44U3R2?=
 =?utf-8?B?OUJoeFViR3YyL2pNQU13SmhycmcvcDRHMkMzaWplQW0ySU1yS251RmhFbUFJ?=
 =?utf-8?B?MzdxamU5Mm5jZEFGTzBNaEJhaHBWa0EzblJoM2Eyc2JpVG5NYklxVnk5U1A5?=
 =?utf-8?B?aW5PbCtGT1E5d0dCS29TTXNkL2VFTWtnNkRDbjU1ZFpjQml3dVE3eUtGbHdJ?=
 =?utf-8?B?bnhGcWFZcEp5RXI0akVCb051dVlObFg1WlZWdC9weUE2OTBLa3R3Rlc1Q2ky?=
 =?utf-8?B?Z28yTDV1SC9BYVNmVHA5OC9Pc1ZCcDhUanBFS0hGWUsrd1A0MGQ2NTJESXlK?=
 =?utf-8?B?SzdGL1VhcmxoY0ZvdWhaQnovOU5xb2FUNDU2KzNDNEFyVVhoUzREUkRJaEpt?=
 =?utf-8?B?M2oyZUx4WXpPYkVOenppajdpd2NBbWt0c3Q4Yk5VZWt4STZQbmRpenZsY2VF?=
 =?utf-8?B?bGpWVExSOUd5OUMvT09nbjQxYnhFbHVsVmp5cksvQXY2TC9zU1QxOG91Nmg5?=
 =?utf-8?B?NFhkanN6YnFIaG9BSmJmWUFuNGF1VG41S25FQWt5TGV1OTVWYnNtelZCVytv?=
 =?utf-8?B?bG43T1RQVUFIVWJlc1ZWNFo2bytvRUFMTjdJbHoyM0tIR2hqdGU5QngyR0JJ?=
 =?utf-8?B?d2FXQ0dlUkpvdHlWZDJLa0NEZDJtc2d5WVNhY0RiSHVHQzJnazdna0RlYlcr?=
 =?utf-8?B?S1RMWHNkcTI5YWM1c1J4UlIrR1RTWE5DQjlKRHFTL1BjMENFdGJXck1Ma2lq?=
 =?utf-8?B?U2kvUVhxbGlrMmhWTE11cmhmYjdEWEtxUFFhdktJMFRScWxzZiswbkhsbUFU?=
 =?utf-8?B?RCs2a0oyY3ZFQVdvTERWTHB4dlNRbkV1czczNVNDdE9ZbkhlbU5OSWN3cUhC?=
 =?utf-8?B?eENrQjBReER4RHFrYTdmN3FTVlZCTWFkWTAyUFFicDJOMHJ0UjFDZnhjVGRW?=
 =?utf-8?B?ejFLNTZmOUxqNWdxVVhEcDdmTlprK2tITWpvbjhaV3RlV08xU2RCMlNEZWEy?=
 =?utf-8?B?NjBJN1ZhSTNpZ1pwdXhWZXBRU3hYajdTd3NEWlB3UUNGRWlzUFBsYTF3aER2?=
 =?utf-8?B?bHpiaUZPVXdPaG11RGZzUitWY1ljSDRMckNPOThFRytwZG5tVTJrMks5NnpS?=
 =?utf-8?B?K3hrWVlmM3ZQLzRWYjl2VUJacTV4YnMxeVkyYzFJYXZ6elpyajk1Wk1ydU9l?=
 =?utf-8?B?SnJ2b0owS1l1R3QxZFVJd0p0aTR2MklSemxBb002NHdJcmJXZ2t0a3loMU50?=
 =?utf-8?B?TmRLcWNxVVN3am1UQ0Qxb1I2blJYSC9mZ0kvc0k3MStOU05Ucy96M2VQcmM4?=
 =?utf-8?B?M0Q2L0Z5Ny85cG1zbWpPQ3lYSDRRZ3BndTlXOUtuNjZ3Y3BkUW5WUmN4RDcr?=
 =?utf-8?B?YzdHV3pvWkJSZGYyN2ZkQzJDWHgrOGE4dU1tZklwRlRnYVBJaHJFTGNVcDV6?=
 =?utf-8?B?R3hUTUdBTXQydmNsQXZmS2tlcTFiSGdrNUdQR0dYeWMwUjZCaERJOHZZUk9w?=
 =?utf-8?B?RFZ3U1pNV2FVUDlKN2pVblFqd3dMZGN1SjhQbFBuRGtDdVpjbHRZQTJYZWJM?=
 =?utf-8?B?bUNZYnFrWnhuZDlPaXc0UkhFTkFsMmErc2hxd01nZnAxTU82OHMzcVRPWHgx?=
 =?utf-8?B?MXhLcDBTUDFCdTdtUzNIUk9Bc0hNdDNPWWEvT1hvbzNwNTBheXplL2VUQXp6?=
 =?utf-8?B?bHhFVjFGZndFYzBYR2FyZmxEWXpaaEpaNjJ6STVna3NDRUdDUVdmMTZUanpn?=
 =?utf-8?B?Y3V1Sm1XUFBCWlJaNmxNajhWRFJ0dUN6bDBWR3o5UlUzU3FMMTh3WVIra3lC?=
 =?utf-8?B?Z1E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a3dc6d7a-49e3-49e6-5c36-08dc80e67188
X-MS-Exchange-CrossTenant-AuthSource: SJ2PR11MB7573.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2024 20:24:01.6262
 (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: KuWUT5cnmJRMHLF0dpmSTOE0htCVX2kcLPX5TZARO987oRw4gyrOIiyGPs7cG714J8to8yBLotcQFjrBvetxV7RKtA75e3jqA0N+YC3brGE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6772
X-OriginatorOrg: intel.com

Hi Tony,

On 5/28/24 3:19 PM, Tony Luck wrote:
> mon_event_read() fills out most fields of the struct rmid_read that is
> passed via an smp_call*() function to a CPU that is part of the correct
> domain to read the monitor counters.
> 
> The one exception is the sumdomains field that is set by the caller
> (either rdtgroup_mondata_show() or mon_add_all_files()).
> 
> When rmid_read.sumdomains is false:
> 	The domain field "d" specifies the only domain to read
> 	CPU to execute is chosen from d->hdr.cpu_mask
> 
> When rmid_read.sumdomains is true:
> 	The domain field is NULL.
> 	The cache_info field indicates that all domains
> 	that are part of that cache instance should be
> 	summed.
> 	CPU to execute is chosen from ci->shared_cpu_mask
> 
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
>   arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 28 ++++++++++++++++++-----
>   1 file changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
> index 3b9383612c35..4e394400e575 100644
> --- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
> +++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
> @@ -517,6 +517,7 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,
>   		    struct rdt_mon_domain *d, struct rdtgroup *rdtgrp,
>   		    int evtid, int first)
>   {
> +	cpumask_t *cpumask;
>   	int cpu;
>   
>   	/* When picking a CPU from cpu_mask, ensure it can't race with cpuhp */
> @@ -537,7 +538,8 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,
>   		return;
>   	}
>   
> -	cpu = cpumask_any_housekeeping(&d->hdr.cpu_mask, RESCTRL_PICK_ANY_CPU);
> +	cpumask = rr->sumdomains ? &rr->ci->shared_cpu_map : &d->hdr.cpu_mask;
> +	cpu = cpumask_any_housekeeping(cpumask, RESCTRL_PICK_ANY_CPU);
>   
>   	/*
>   	 * cpumask_any_housekeeping() prefers housekeeping CPUs, but
> @@ -546,7 +548,7 @@ void mon_event_read(struct rmid_read *rr, struct rdt_resource *r,
>   	 * counters on some platforms if its called in IRQ context.
>   	 */
>   	if (tick_nohz_full_cpu(cpu))
> -		smp_call_function_any(&d->hdr.cpu_mask, mon_event_count, rr, 1);
> +		smp_call_function_any(cpumask, mon_event_count, rr, 1);
>   	else
>   		smp_call_on_cpu(cpu, smp_mon_event_count, rr, false);
>   

Why not provide the cpumask as parameter to mon_event_read() as I asked
about in previous version (again feedback that was totally ignored)? With
this implementation there is a portion of SNC logic in rdtgroup_mondata_show()
and another portion of logic in mon_event_read(). Scattering SNC quirk logic like
this makes this very hard to understand.

To help with understanding this code I asked _twice_  ([1] and [2]) to
_at_least_ provide comments for these SNC branches but even a request for comments
is totally ignored. I even provided some comments based on my understanding
that could have just been copied&pasted (if it was correct), but that was ignored
also. I understand this work has been taking a while and to support this I am
trying to spend more time to review and provide more detailed feedback but to
find it just to be ignored over and over is extremely frustrating and wasting
so much of my time. I do not expect that you do everything as I propose but if
I propose something silly then please point it out so that I can learn? At this
point I am convinced that you find my feedback not worth responding
to leaving us stuck with me who keep trying to review your work and getting
ignored over and over in every new version.

What should I do Tony? Why should I keep reviewing this work? Asking to address
review feedback should not be necessary yet I seem to keep doing it. An attempt
at an ultimatum was futile since it was just dodged [3] with burden placed right
back on me.

> @@ -575,15 +577,29 @@ int rdtgroup_mondata_show(struct seq_file *m, void *arg)
>   	resid = md.u.rid;
>   	domid = md.u.domid;
>   	evtid = md.u.evtid;
> -
> +	rr.sumdomains = md.u.sum;
>   	r = &rdt_resources_all[resid].r_resctrl;
> -	hdr = rdt_find_domain(&r->mon_domains, domid, NULL);
> -	if (!hdr || WARN_ON_ONCE(hdr->type != RESCTRL_MON_DOMAIN)) {
> +
> +	if (rr.sumdomains) {

	/* Explain what this does and why */

> +		list_for_each_entry(d, &r->mon_domains, hdr.list) {
> +			if (d->ci->id == domid) {
> +				rr.ci = d->ci;
> +				d = NULL;
> +				goto got_cacheinfo;
> +			}
> +		}
>   		ret = -ENOENT;
>   		goto out;
> +	} else {
> +		hdr = rdt_find_domain(&r->mon_domains, domid, NULL);
> +		if (!hdr || WARN_ON_ONCE(hdr->type != RESCTRL_MON_DOMAIN)) {
> +			ret = -ENOENT;
> +			goto out;
> +		}
> +		d = container_of(hdr, struct rdt_mon_domain, hdr);
>   	}
> -	d = container_of(hdr, struct rdt_mon_domain, hdr);
>   
> +got_cacheinfo:

Something like "read_event" would be more appropriate since "got_cacheinfo"
has no relevance to non-SNC.

>   	mon_event_read(&rr, r, d, rdtgrp, evtid, false);
>   
>   	if (rr.err == -EIO)

Reinette

[1] https://lore.kernel.org/lkml/2a7cc72a-99fb-4862-b7eb-da3d515f0453@intel.com/
[2] https://lore.kernel.org/lkml/ccd5df99-4d7e-4224-a07e-3897e370b53e@intel.com/
[3] https://lore.kernel.org/lkml/41cc8a35-81fb-b890-f963-8dc9524a54b0@intel.com/