Received: by 2002:ab2:1347:0:b0:1f4:ac9d:b246 with SMTP id g7csp435815lqg; Thu, 11 Apr 2024 07:25:49 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUrH11W5ufcPffOBEFoS8xhKOP3aPdAYN/2hjClsD8XxvrnVR0Rwbgd/yBaxSG5cGpJlHRH1G7oHNH49oVcKUuP8cY5fHojhBIkHGS/8Q== X-Google-Smtp-Source: AGHT+IEzORFhDwYAgOVIkcmE6r9hAcT/pPzdiQ1FMEusPXY3uJNTjfd6zd6Aoqvmbc5fzPu4dR6w X-Received: by 2002:a05:6830:1484:b0:6ea:18aa:a837 with SMTP id s4-20020a056830148400b006ea18aaa837mr6486479otq.25.1712845548978; Thu, 11 Apr 2024 07:25:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712845548; cv=pass; d=google.com; s=arc-20160816; b=cewwqXBYuRIIYHEu43myar8KGyu7LPnpSgtyQQr04uLBU+kdigaL5Y3zLxLOLCkqG/ 6f9LT4ElOdy+oxUVj3f4/adMt118caJ9ZzF5ofliF4Jx7poioNUTjF/0ISwLlHgUQlpv stvV0gdxHHzVbdIEToIxSpHl65DkgD8LoW4ERta2CYz+w4ImCJo/fc7khCyHMzmsz4/X Q8EPjRZa9zBwjm5c90jnwGcRaShIxICzKBUFrIQQc9/E0QbnjjuzNZhfH16AYdu005bT v4yZinRfkRgVm6TTyV4X67Pfmqzivs/rWrH5Eyp2/xNck6T3+b3A4pwfxkfToOsm0NHY MuYg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=Kj3aCN/3w6UbVZi0w+POR8XkkSW7HRaq3b6Ykn9Ix9U=; fh=QpfXcl1MWRNwK/PrSFDaf8vyLNOqSjtq+qtJ/l97qlo=; b=EHQM8Kro6EYMlHtJ5Z8YnpSslXR2i0vDNAyEd6MExQt4pNuA9RVdjI6fSl3LCmEx0O sTMsah//8rdF3caQT1LDsiMdIuolrYhn+o+B98x1hICwdakoBoaaM2syxsS/ya7cUCFY Hj8Zd0D4gnmeYCGuIipDs06XfeIxyr7S1LGXC8fLPe6ausrTo17L2Go+bDgiL6PQNV1F coO7oAH7MYnrQX+o7SllfSaElvwTRexZSg0B3i7XwVFUdc98YjBc9IP5Zpl2RC+CdlpV TvptElGSpCCIkV2OFOpLs5r0mXuK+GtkmJEoo18TnRf1ArUL7m+UdxbR4eAy7JT36+xs C2OA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-140638-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-140638-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id t10-20020a05621405ca00b0069b40717220si1517671qvz.526.2024.04.11.07.25.48 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Apr 2024 07:25:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-140638-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-140638-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-140638-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id AE1201C226BE for ; Thu, 11 Apr 2024 14:25:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4BA3114EC40; Thu, 11 Apr 2024 14:25:42 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A2F114D443 for ; Thu, 11 Apr 2024 14:25:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712845541; cv=none; b=A9veS2PKWIxyRRwoH8mlrUvi3FClRxRNcgqgOt4ZIAqRjHSh5xaO0y9pkOQKc+DzyWw8xCweW5YfSIP3ShZNvuroFLlSrM8TNfOT3YU151dfJeA0M7IfaNtNQvBU37YOfCUai8M332y57PVYagf6kY2+g0dRW1NC71o1wWfDut8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712845541; c=relaxed/simple; bh=kzC5I+jlXQuHmHtY/Zni2LwuxXuCXvts4jC4WgFE5kQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cXS1nerAmZghyaR+FuWGfKPTSowNDCiN6DTwrnSsRaV4lDvmvoatZ14tp/jsmn5k/gYc5A0eV+KUjX73Calmc0e3Isn5Ol1R1MqNuEHIJATNTjfBSoQukzlTPtVbeA0raad/XQ2y6Dgt+i6HdtbpMXFnxDGSiKmnYz61qI0tyCU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DB5F4339; Thu, 11 Apr 2024 07:26:08 -0700 (PDT) Received: from e133380.arm.com (e133380.arm.com [10.1.197.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E40E3F64C; Thu, 11 Apr 2024 07:25:36 -0700 (PDT) Date: Thu, 11 Apr 2024 15:25:34 +0100 From: Dave Martin To: Reinette Chatre Cc: James Morse , x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Babu Moger , shameerali.kolothum.thodi@huawei.com, D Scott Phillips OS , carl@os.amperecomputing.com, lcherian@marvell.com, bobo.shaobowang@huawei.com, tan.shaopeng@fujitsu.com, baolin.wang@linux.alibaba.com, Jamie Iles , Xin Hao , peternewman@google.com, dfustini@baylibre.com, amitsinght@marvell.com, David Hildenbrand , Rex Nie Subject: Re: [PATCH v1 24/31] x86/resctrl: Move get_config_index() to a header Message-ID: References: <20240321165106.31602-1-james.morse@arm.com> <20240321165106.31602-25-james.morse@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Apr 08, 2024 at 08:25:26PM -0700, Reinette Chatre wrote: > Hi James, > > On 3/21/2024 9:50 AM, James Morse wrote: > > get_config_index() is used by the architecture specific code to map a > > CLOSID+type pair to an index in the configuration arrays. > > > > MPAM needs to do this too to preserve the ABI to user-space, there is > > no reason to do it differently. > > > > Move the helper to a header file. > > > > Signed-off-by: James Morse > > --- > > arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 19 +++---------------- > > include/linux/resctrl.h | 15 +++++++++++++++ > > 2 files changed, 18 insertions(+), 16 deletions(-) [...] > > diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h > > index 3de5bc63ace0..73c111963433 100644 > > --- a/include/linux/resctrl.h > > +++ b/include/linux/resctrl.h > > @@ -258,6 +258,21 @@ bool resctrl_arch_is_evt_configurable(enum resctrl_event_id evt); > > void resctrl_arch_mon_event_config_write(void *info); > > void resctrl_arch_mon_event_config_read(void *info); > > > > +/* For use by arch code to remap resctrl's smaller CDP CLOSID range */ > > +static inline u32 resctrl_get_config_index(u32 closid, > > + enum resctrl_conf_type type) > > +{ > > + switch (type) { > > + default: > > + case CDP_NONE: > > + return closid; > > + case CDP_CODE: > > + return (closid * 2) + 1; > > + case CDP_DATA: > > + return (closid * 2); > > + } > > +} > > (please check the tabs) Noted. I also see that redundant parentheses seem spuriously added compared with the original version of this moved code. I can make a note to drop them if you prefer. > This change is unexpected to me. Could you please elaborate how > MPAM's variant of CDP works? > > Thank you very much. > > Reinette Note: I haven't discussed this specifically with James, so the following is my best guess at the rationale... With that in mind: For MPAM, CDP isn't a special mode; instead, the PARTIDs for instructions and data are always configured independently in the CPU. If resctrl is not configured for CDP, we simply program the same PARTID value both for instructions and data on task switch. For a given resctrl control group we could pick two random unrelated PARTIDs, but there seems to be no advantage in doing that since resctrl enables cdp globally or not, and we would require more effort to translate resctrl closids to PARTIDs if we didn't pair the IDs up systematically. (See [1], [2] in James' snapshot, which illustrate how he proposes to do it.) So, we may as well stick with the same scheme already established for x86: nothing forces us to do that, but it looks simpler than the alternatives. I think that's the idea, anyway. Then, if the same scheme is used by multiple arches (and 100% of the arches currently known to resctrl), it probably makes sense to share the definition of the mapping at least as a default for arches that don't have their own different ways of doing it. Does this make sense? I can recommend adding some of this rationale to the commit message if it helps (and assuming I'm right!) Cheers ---Dave [1] https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/tree/drivers/platform/mpam/mpam_resctrl.c?h=mpam/snapshot/v6.7-rc2#n206 [2] https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/tree/arch/arm64/include/asm/mpam.h?h=mpam/snapshot/v6.7-rc2#n146