From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14A8D349CFE for ; Thu, 11 Jun 2026 17:27:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=198.175.65.13 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781198872; cv=fail; b=fmvsT0BYYewxhDQCdbH6q2owwptSiScCfAQjCW1tF3btqDafRIicGHHBdzvSU+E0pXXB55tnbmv4WO9nfvovErfSqlbC0KEGNm/IEu1zBfx1nZWV2jvKW4U2pZfIjWAz2YVz2QNaq6G28yK73wyE4BvBjmnkClo7PbH6JZMzxio= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781198872; c=relaxed/simple; bh=UFkOC4rkXgTVtogFnt1luavWSIYIObr5v/WfPMEknx4=; h=Date:From:To:CC:Subject:Message-ID:References:Content-Type: Content-Disposition:In-Reply-To:MIME-Version; b=kpPzc7XUvOwxIx1vBxkDalsfZTSrJ2dJl1U9SadmUJ/UmRBqVa2SgReyseJWdUQvsiyZ6m+krm+iSkv/Je19xyEXUJkRSbtMyUbaQzBwGIRWIehUqtwl0HfzyNSA5G4igBl0P0dfq9FaqJ5MwSvzAUgwIDQ8GYqzfO0fOWPYT9M= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=EuDvK8k6; arc=fail smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="EuDvK8k6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781198869; x=1812734869; h=date:from:to:cc:subject:message-id:references: in-reply-to:mime-version; bh=UFkOC4rkXgTVtogFnt1luavWSIYIObr5v/WfPMEknx4=; b=EuDvK8k65Ek3WzFe8M3kbJbPAaEfCgqQA4TFMSYEEhV70vhsPhTiD8YF cHwh2dexeORnp1QCcO/KRmsj/nmTfqf+jROe+u6WDAnMl7B64zH083Gvi Nm4EsWOLdRUY8LXg11DHClZBXOZLRmLWiql2YFoF44DyxSXK3VsHOfz/u qkYpwYuwacCC0MZXW2ddaB6bFi/+y+/qOipqc1fFP9yKcikb/lg2JasKp sfLxLmqSP4DdrKSov6xAK1ISUJxzogDQcZLG5W5vs65AFDzbEKBxWwwiw ie3a8oVYPDO/Baz4rHnQe2zrSiJjYIJ95yjqEXNBbsbgOLJpayXYJl3N3 w==; X-CSE-ConnectionGUID: uhDshhJZT72kC9msTB6lDw== X-CSE-MsgGUID: lVB5dZ20Tler5IQe6ks1wQ== X-IronPort-AV: E=McAfee;i="6800,10657,11813"; a="93130125" X-IronPort-AV: E=Sophos;i="6.24,199,1774335600"; d="scan'208";a="93130125" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2026 10:27:48 -0700 X-CSE-ConnectionGUID: R1SB1poMRTSsZI1yfEYd8g== X-CSE-MsgGUID: LhdFCDbPQkKeBoCgMm26LA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,199,1774335600"; d="scan'208";a="242416248" Received: from orsmsx901.amr.corp.intel.com ([10.22.229.23]) by fmviesa010.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2026 10:27:48 -0700 Received: from ORSMSX902.amr.corp.intel.com (10.22.229.24) by ORSMSX901.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Thu, 11 Jun 2026 10:27:47 -0700 Received: from ORSEDG901.ED.cps.intel.com (10.7.248.11) by ORSMSX902.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37 via Frontend Transport; Thu, 11 Jun 2026 10:27:47 -0700 Received: from MW6PR02CU001.outbound.protection.outlook.com (52.101.48.41) by edgegateway.intel.com (134.134.137.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.37; Thu, 11 Jun 2026 10:27:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LoWFrZTsl/tUbBASaIfOlZLoo7QGWtIl32mgdjVtM2txHXd8ShmPNDKeGIzZAaFl3DF9mFIesyGGZvSXP1OVZTBnrfM+zliCGzRbz+UDiItqY2GEgKEojUxOwqEBKGkHAhp0a7pWv0wStn1MOeYSheqYwFu7eRN0N7/R61i3XpLD+yapuH+oTBmeOCL/nTwwOW42qrRfibgt4I/TrTeiaBKON7ts1BENSeU0+g4gj4gSxtPf87O0WPBxaRwqtZjHwMtuk61ewdbs77vWQjgmC0QG1qlo7mwXOEZrUKtmIoWRXUuWl5/ujBKRjkxmPUKeLWTPbRjpzPe+oSJRJwzqNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xVn9vw7PF/lqOEERLtK00nS3JjmwFrAXOiYtoGYJuMw=; b=spPJapTvcme9LONE1RAkmG9qIrCVR5CQFruce3XXAvKhTE1B2CToojwsnhFqXPYFPrRUJQBtnvyZeJiUTWiKbx284Ac4yT6dlGttA0/W1ns8e4wzzLkQEDQJ4/hF7U9Eb5esr1/w9xHfLjOtZPUak/iG62EP4+Hv+LTsbN7JuMUoJBP8Dj+icohp7mTRQJJYzNYreyYlk2rdriw0+4826tos72yUZD+AdBy9TssS5Srm9DQCEcRkP/n5HUyQEVACCd2MEo+ZvSc6omgfxr6ONOv9WDnZLoxjdrAD2NIRxUmV0CVWVByjWyvWhnIgJKGJru/sENWSdgmtcAOMFj4QgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from SJ1PR11MB6083.namprd11.prod.outlook.com (2603:10b6:a03:48a::9) by SJ5PPFC295640A5.namprd11.prod.outlook.com (2603:10b6:a0f:fc02::852) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.14; Thu, 11 Jun 2026 17:27:44 +0000 Received: from SJ1PR11MB6083.namprd11.prod.outlook.com ([fe80::3454:2577:75f2:60a6]) by SJ1PR11MB6083.namprd11.prod.outlook.com ([fe80::3454:2577:75f2:60a6%7]) with mapi id 15.21.0113.013; Thu, 11 Jun 2026 17:27:44 +0000 Date: Thu, 11 Jun 2026 10:27:41 -0700 From: "Luck, Tony" To: Reinette Chatre CC: Fenghua Yu , Maciej Wieczor-Retman , Peter Newman , James Morse , Babu Moger , "Drew Fustini" , Dave Martin , Chen Yu , David E Box , , Christoph Hellwig , , Subject: Re: [PATCH v7 07/14] x86/resctrl: Maintain a count of enabled monitor features Message-ID: References: <20260601195632.15876-1-tony.luck@intel.com> <20260601195632.15876-8-tony.luck@intel.com> <40404fc1-c355-4848-af2c-f39f8b3b03ba@intel.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <40404fc1-c355-4848-af2c-f39f8b3b03ba@intel.com> X-ClientProxiedBy: SJ0PR03CA0250.namprd03.prod.outlook.com (2603:10b6:a03:3a0::15) To SJ1PR11MB6083.namprd11.prod.outlook.com (2603:10b6:a03:48a::9) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SJ1PR11MB6083:EE_|SJ5PPFC295640A5:EE_ X-MS-Office365-Filtering-Correlation-Id: e20108a1-a98a-48ac-b95e-08dec7debee1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|7416014|376014|1800799024|366016|23010399003|6133799003|4143699003|56012099006|5023799004|11063799006|18002099003|22082099003; X-Microsoft-Antispam-Message-Info: IUywN0i3bBrlVQMIH0O5EvhnxCT4/LhBDK/I+fuQGpM1U24rTJZiwkcSMKeu5hiT0KEGSJfFGOxinouPP2pHEcrEzzKBno4kA96d3fM430RwLEfjg/NfbjsrNNvIsXHuobq3kH9DpAv9uQimcvIT9yWR4KEu/hTPr81OK4IQ3Iws4ctk9ZV2PcSFouCOggsYpTEmRSIfqWHlSPcPA3AX+d/XttUW9p6p973N4SO8fUZHI1FxFSSNmjbougp65U2ot7nKsyv0aiU9/I9m0YllTB5iA+yab4KEqyhgzdjkFid5Dz7k4eu0t12N6kU5FJmNvoKfJ9EpE6GrSZgDzAs6IJsUnUOfP0awd6+qO95UBoLH5w/mzjW45x7WFxrsj6w1K+Qy7uJgihAYSt5gZuh8xp0IFMSOVVpf24z2mJ7pZ/w4ngiVeDqCk+bXkQVTxPXfmt3sokpzKHRUO8BV/PsVQkq532qkN0U94zinyQaEetW5uMB+irSWJYRoPISuMrPNtripfddU8uuwyEf1+KcqTEM3e1n1vhyOM0CLxzDX0UUNWu5MMwgE6lL03VVXeOPp2l951jm83JjIbkABoA5/2vfOoIBL7QuFMQN+wcUXVe1QTymjB23Bj/6O0KqRmtkNXPdh+WsXlGFkdmIY58qfFADtF0D9p5aB/VJWq7KifHSjDRJb35q6bO7UNGgYjJye X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ1PR11MB6083.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(7416014)(376014)(1800799024)(366016)(23010399003)(6133799003)(4143699003)(56012099006)(5023799004)(11063799006)(18002099003)(22082099003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?sQ/cdRmipycJqZBJ3VX6agAmcEEO69f6xyEozLZXRAk96B9CQz9NHGm86oVL?= =?us-ascii?Q?JechOgOUbhxyc2LG0Gd7LB85O6jihhT7T64HuHv0FJaYROUwVMcP7DT3DDzW?= =?us-ascii?Q?Y/4UqlrbvBTiS5qnuVgCGCLirqRKmfZnHLzfeDamedUFftFdoLHR361PDkf5?= =?us-ascii?Q?Xh37AY9DnJudT9miBNDIdfsjerknxBfxZLizYUCJuCU1tYp9UrKAuVw47SU3?= =?us-ascii?Q?OYTiwGOUrlUbSIHvtokBJrNWS7qc1aZaJKdoN4/55jstO7+5gDH4duwEyafe?= =?us-ascii?Q?VHtVt5V6FfHJWAhjoNeEtgoEdYrQCwBUsywjDD5aHg5t8nT388eZqaXeqkLH?= =?us-ascii?Q?3thcAukIkM4YvABoKHtTQQsQaZ8w7OuSI4Tu7lJ+7p0c7j+AkqkKQsZY+CeM?= =?us-ascii?Q?Mr9x8Ty7eI48o4CSE4qqNTCL9SZagl6fr5432ayjQWs2/BJpB7+rlDMm6uQC?= =?us-ascii?Q?xGdzaEIyNYbdImU4hsliGzrCg+D5IMzxCTYTK0L6K58ArxsZ8U+YelEpJSaR?= =?us-ascii?Q?vrKT1zcW4T0nkpVwzoiYwhCFTZcKWhNp/Y6cHG0MKMmLOqrdDHozdDaC7Yw8?= =?us-ascii?Q?Gz8SYSsjFP4lVp1/dhUAL01WxsvnjBKaFi1xJOZuNgYJPSEpEy9zKj6P4p9f?= =?us-ascii?Q?D72AGVdNDgfW7RoOAXvUQpjwS3jqmaEITqNpGEri4bTn8f78hBr45VrrGUM1?= =?us-ascii?Q?8cSU2V7Lw0WrUJzjUb5yyzQ7A2ROy2LU8qqOOuY+jCVqv+mJTQagMx6AfPIj?= =?us-ascii?Q?4VAxDi3Am5vpoRQuXAkb3iHbc8v83gKldfmh3eZkz03f85glOzbyG/SvSsEa?= =?us-ascii?Q?bZUW9bYSc+Yvj8LOq8caGWN/VsjiokwMLbdNYt9YzwsS/PI/65H+yrcDorky?= =?us-ascii?Q?+6xlYOjk1NqGmNCfV1fJ0lpQTgQsAvSYY0gJnJyHIm5yGp1ekf489kzt1L8Q?= =?us-ascii?Q?/RvGIgi7AcgJEbaI88mw+wAOAbSJCuu6gOnpxVMkbpbEEnlAtHED96Ub4QE8?= =?us-ascii?Q?rqYfNm5eoUZXBFrVnKMzwIuTuu1rvmhQUDliKVq8Ju3w7RRIV90OOAeenklI?= =?us-ascii?Q?jL0GF/sKZlZgGVivbGRPgjUSRACqNpZmVJqhaMC+qtT0ShBgCtnz4OJMmIk4?= =?us-ascii?Q?J9DZ8udt0dYF5MS4Z779LCTWwmZ+WmS9pNjUDBMmL+nT9TTLo3tCh1VPSGPZ?= =?us-ascii?Q?83+FATDthlQJCwrieCPTUtN5XOychxCeG5kDkUL2a9bPlMLjrDjm5ZuQcTb2?= =?us-ascii?Q?Ybx0vCjqs/59T5raUzKgyPMiDQHOP59zbUin2l4lkiC8sw0rnyhNbfBxMocH?= =?us-ascii?Q?Seojtz+KP9skNK1M/mUfPJHvRPBtJLXuiZHIrjuoqtfmrepET3OrGqRRryJQ?= =?us-ascii?Q?RNLu449Wckf7xPJXWayp5Qk97QpSsTPDbSNPCNPCN6vk2/igTyP+tqTyeZCU?= =?us-ascii?Q?F/dbvevE3iFlWvtSA27vtstE5vEVVHNV9cy5Y+lzAM/Q6no1QGjpvfH9iG+y?= =?us-ascii?Q?b4oJGruYxcfcr+Kv33CzYhKd2ai5C9Y7/r0gQzQjqAG/96N86iTccZHDXXHb?= =?us-ascii?Q?/VIFZY38LEo2L7Yt7wX3JJNQ4a7ZA8o+YrdmoRNGeGiDnN1wllnhwRltOyem?= =?us-ascii?Q?BQkxODING99+rAh/HFattd2rAVl0FCsQ+o5teccVekdSBuucaFEX0u5ReVJk?= =?us-ascii?Q?taJeJF2f1p6I1sa8591nyb81UtQR7mljKsnS/s0kTDtPQkbYRGk/VrYR0wHa?= =?us-ascii?Q?PWoz6yyFUA=3D=3D?= X-Exchange-RoutingPolicyChecked: QGkrQ6MPUYRx6errgRDhddW+Cg0zYaGtfA1j0PfJjzkLhgwcVqvNQoXg4hXVGyoGWLYz16wT0I/LAdwfvk2mmdUQ4v2WPFscAdI/oDuWvdnRo91g2JEAIjGrijMK8azc13W2e9dnjcfXqXP7ScwqDv1/wGp2vcyoyKsckxUh5ABXA8D7yX7zhkkkxZPDya4HWlnMuZtNoATTPpRioLmiVpXwHGulV0ODIDPU0Xjbls3Zg8VIFdUth5TlIiKsw0KqT3lHzTAIKSIedzevzB2uUplJOIGE030d3yMTyUZ8ZGD6gTODcXWR4ugQpDBsJOBRZ9DTnhmMQxWKtMPfMcx6KA== X-MS-Exchange-CrossTenant-Network-Message-Id: e20108a1-a98a-48ac-b95e-08dec7debee1 X-MS-Exchange-CrossTenant-AuthSource: SJ1PR11MB6083.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jun 2026 17:27:44.1200 (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: 8YUjzaa1n50IxnbALNPwxvJDTEC66q5CEvzljcALqOe4H4WnyWDVx/UoUyoGoElnD0Y7kja4rnwx1DlrNeT7Mw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ5PPFC295640A5 X-OriginatorOrg: intel.com On Tue, Jun 09, 2026 at 04:03:53PM -0700, Reinette Chatre wrote: > Hi Tony, > > On 6/9/26 11:46 AM, Luck, Tony wrote: > > ... > > > Conceptually this is much simpler. But I have questions about the > > implementation. The new function is trivial: > > > > bool resctrl_arch_mon_capable(void) > > { > > struct rdt_resource *r; > > > > for_each_mon_capable_rdt_resource(r) > > return true; > > > > return false; > > } > > > > But that led me to #include hell when I tried to keep it as an inline > > function in because for_each_mon_capable_rdt_resource() > > is defined in after the #include > > > > So I've moved it out-of-line into arch/x86/kernel/cpu/resctrl/core.c. > > > > The MPAM implementation is also out-of-line. > > > > But then I wondered about performance. This change on x86 goes from an > > inline function that simply returns the value of a global variable to an > > out-of-line function that scans the array of rdt resources. The common > > case will be a hit on the first element, so not awful. But still worse > > that before I touched it. > > > > So I looked for places where resctrl_arch_mon_capable() is called in > > "hot" code paths. There's a bunch in mount and mkdir, but those aren't > > very hot. > > > > My list (check to see if I missed any others): > > > > 1) Recurring call once per second in mbm_handle_overflow() > > > > Seems redundant. There is a check to only start the overflow handler > > on mon_capable systems (only with enabled MBM events!) > > > > 2) Call for potentially every task when reading tasks files in is_rmid_match() > > > > Also seems redundant. Next part of that "if" looks at "r->type == RDTMON_GROUP" > > which can only be true on mon_capable systems. > > > > Should I clean these up in this series? As part of this patch which > > exacerbates the performance impact, or as a separate cleanup patch? > > Thanks for catching this. I think it is reasonable to include it in this series > as a preparatory patch with this patch helping to motivate its inclusion. OK. I'll add a new patch to the series for this. > > Even so, I am now a bit confused and concerned about the PMT dependencies. I am > not very familiar with module_get()/module_put() capabilities - can it be > guaranteed that PMT remains accessible between those two calls? I peeked at the > sashiko review and it mentioned the usage of "unbind" triggered from user space. > It sounds to me as though PMT's .probe() and .remove() can be triggered at > various times from user space irrespective of resctrl being mounted or not and not > prevented by a module_get()? > > So, consider scenario where PMT is loaded and then resctrl is mounted and user space > creates a couple of monitor groups that contains the AET event files. What will > happen if user space then unbinds PMT? From what I can tell this will not > trigger AET unmount like resctrl unmount would and thus leave a lot of dangling state? > > Back to the above ... if AET needs handle a PMT unbind, do you think that, for > example like in is_rmid_match(), that resctrl_arch_mon_capable() could return > different values during a single resctrl mount? I'm pursing options to prevent the unbind (until someone tells me there is a critical use case that needs this to work at any arbitrary moment). If preventing unbind works out, then resctrl_arch_mon_capable() won't change during a single mount. > > Reinette -Tony