Received: by 2002:a05:6500:1b45:b0:1f5:f2ab:c469 with SMTP id cz5csp78154lqb; Tue, 16 Apr 2024 09:14:38 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWUXQQdktXd1burt7GONJ3lclEsIaETlb+Ydi7IYB2BFUYPCCzNijqyhfOeaUD68/tuB3vi7dFWPyzuJymDhF1oZzcXUfUW4Q3yfkH/aA== X-Google-Smtp-Source: AGHT+IGh9Q3aHYc2/o61Fx9HKdGXEC1KOFx+cKlLk/WVwwFvee22kq8t/kOhNUGFVMf5+jJYZVip X-Received: by 2002:a05:6358:d00d:b0:183:7d27:c08d with SMTP id ja13-20020a056358d00d00b001837d27c08dmr21244744rwb.32.1713284078131; Tue, 16 Apr 2024 09:14:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713284078; cv=pass; d=google.com; s=arc-20160816; b=N0LqcQfcyP3d9PCRpwtDrU3sbeZ2VRVcC6KqJF9Tz02DRtpfa+y5AHc2HEEpb/FfCB epho6t00UmyA20v+2CClXKrR5bd8Yl6klrBXaAjTkBzPDBv+ItGZqUC7VCiKvA9NdO5R 2UiPrtKxa9IeHnB91JH2T+FZHcFDzwo5WJDJz4npZW+pQ0pYT4M1R+lpXnst0KW32Ixt yMKXJS4rfFMGTZJtSYT/iGQLG7oUODccXJJliTiE3QI5wAoAi/xy2M211ErEMtTwqQMY fBGL6w7zhuaTv6NwVk61v8BwfIdYWCxq7AVcnIXqqTd7yjQIJXq3SEAyXiNfIF5u6IqQ KH4w== 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=41d41UuFyFZ6bT7z9EUW5cQNiTlAB0lu4sQbW8e9Jkc=; fh=L6oQMsqStS2+GypcEamznIi2La9bk6Ty8v+876JmcVU=; b=oYR1QlDnbP8vhRRuhqSdtacZWpqNUTLOaz2GhvIeuQiPoqugx63QhkZE26TDythCp3 P55h/aIicJgkzo+xkSTgqGa1EPXDLkCFUeWnHDJ+esIh0eCuZ6NwiN6r/1Sej2H6RkFe UlRx7mYck5A5HDsO+Xekagm1TsVbmYC0oBMHrb0tKQENe7CTHDUMoMx41w5sJ1dNmDmE FIBZnu0FL5MC/2yKMijV38KrWlFln/C2Lk7MVZw1UDuMYHSrkv171m3zNcFK0YheEejk 5JFCribaKrVYIOgAppRGb4g5gFxp2UKFpmKNCZMBLB9HQKdoHZ43UuCF2jz0TKw+fIM6 V3vQ==; 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-147211-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-147211-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 s28-20020ac5cb5c000000b004d35a056f7fsi1841076vkl.220.2024.04.16.09.14.37 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 09:14:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-147211-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-147211-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-147211-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 CDD4B1C21FCD for ; Tue, 16 Apr 2024 16:14:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id C67FD132493; Tue, 16 Apr 2024 16:13:53 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0E6D812BE9F for ; Tue, 16 Apr 2024 16:13:50 +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=1713284033; cv=none; b=V5y9JsndSZSqAt1w2OgcFlMsXtD3p3nbnrFP9mgsTLN9sDRgthWkF+RW5wA+moIMgujYbc/3PS5fL/kQQDJUXrphel85H+2fvbn6grkjoaNRVnK+LJ1HrxmUWs/X8fCpTfDLnMXVcLAQYZj2vZaoCPKWNqiy96hzI+l7+YDHMuk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713284033; c=relaxed/simple; bh=EZiYXcYYhdRml4SnenIKMTRsThmm16vYt8B4S1m+SF8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gFTSwHzxuYqEjQN2Xs83o3bZ8teFfXHPCrks9Po6dGnDObQI7Af09nZ6OTr9pR9gP/Fazda+Ta89EGqDLf9KOwyOQYfthjzLaxpzp/Gsgy1637lMmPotbYS1RK6F7F6gLAlPxFotlVpzrBS1o/VNYrkZnkzZccqHnfT+FJTzHJ0= 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 8E8F4339; Tue, 16 Apr 2024 09:14:18 -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 980CE3F792; Tue, 16 Apr 2024 09:13:47 -0700 (PDT) Date: Tue, 16 Apr 2024 17:13:41 +0100 From: Dave Martin To: "Moger, Babu" Cc: James Morse , x86@kernel.org, linux-kernel@vger.kernel.org, Fenghua Yu , Reinette Chatre , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , 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 01/31] x86/resctrl: Fix allocation of cleanest CLOSID on platforms with no monitors Message-ID: References: <20240321165106.31602-1-james.morse@arm.com> <20240321165106.31602-2-james.morse@arm.com> <36bdfb3c-2828-4188-88b1-b9d01b2a114f@amd.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: <36bdfb3c-2828-4188-88b1-b9d01b2a114f@amd.com> On Mon, Apr 15, 2024 at 03:27:42PM -0500, Moger, Babu wrote: > > > On 3/21/24 11:50, James Morse wrote: > > commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by > > searching closid_num_dirty_rmid") added a Kconfig option that causes > > This is not true. The Kconfig option is never added. It is added later in > the series. There is also comment > on this https://lore.kernel.org/lkml/ZhecyLQsGZ9Iv8wU@gmail.com/ > > > Shouldn't the Kconfig option added first before doing this change? > > > resctrl to search for the CLOSID with the fewest dirty cache lines when > > creating a new control group. This depends on the values read from the > > llc_occupancy counters. See David's comments and previous discussion on this patch. You're right to point out that the description of the original commit does seem a bit garbled though: CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID is not present in Kconfig here, but already referenced by other code. We seem to have a consensus that it's OK to have a dangling IS_ENABLED() so long as the option is added formally to Kconfig later, but it looks like the commit message here should be reworded. Does the following make sense? --8<-- commit 6eac36bb9eb0 ("x86/resctrl: Allocate the cleanest CLOSID by searching closid_num_dirty_rmid") added logic that causes resctrl to search for the CLOSID with the fewest dirty cache lines when creating a new control group, if requested by the arch code. This depends on the values read from the llc_occupancy counters. The logic is applicable to architectures where the CLOSID effectively forms part of the monitoring identifier and so do not allow complete freedom to choose an unused monitoring identifier for a given CLOSID. -->8-- Although it would probably have been better if the Kconfig option had been added upstream, this patch does not create that that situation and the series (taken as a whole) resolves it. So I am not sure that anything would be solved or improved by changing the body of this patch, but if people still have concerns then I guess we can look at it. > > > > This support missed that some platforms may not have these counters. > > This causes a NULL pointer dereference when creating a new control > > group as the array was not allocated by dom_data_init(). > > > > As this feature isn't necessary on platforms that don't have cache > > occupancy monitors, add this to the check that occurs when a new > > control group is allocated. > > > > The existing code is not selected by any upstream platform, it makes > > no sense to backport this patch to stable. > > > > Signed-off-by: James Morse > > --- > > arch/x86/kernel/cpu/resctrl/rdtgroup.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > index 011e17efb1a6..1767c1affa60 100644 > > --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c > > @@ -149,7 +149,8 @@ static int closid_alloc(void) > > > > lockdep_assert_held(&rdtgroup_mutex); > > > > - if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID)) { > > + if (IS_ENABLED(CONFIG_RESCTRL_RMID_DEPENDS_ON_CLOSID) && > > + is_llc_occupancy_enabled()) { > > cleanest_closid = resctrl_find_cleanest_closid(); > > if (cleanest_closid < 0) > > return cleanest_closid; > > -- > Thanks > Babu Moger > [...] Cheers ---Dave