Message ID | 20231031220534.37730-1-tony.luck@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:abcd:0:b0:403:3b70:6f57 with SMTP id f13csp49101vqx; Tue, 31 Oct 2023 15:06:23 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHRxrNN6jlNXzFBjBF/pygpnfc4Y4i0VCKFghGYS3BlpubWAAxlBY5XgS2p8XKL26XIXoKQ X-Received: by 2002:a17:902:f7cc:b0:1cc:3829:8355 with SMTP id h12-20020a170902f7cc00b001cc38298355mr6815347plw.12.1698789982957; Tue, 31 Oct 2023 15:06:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698789982; cv=none; d=google.com; s=arc-20160816; b=EG11upNoaMa8PYTGMVd4uXTZC13fg2M2fXM9T2k6PIMFYdFRTKL7Og2uOiUxf35gXq XqzBmw/Zj7afkcsFPZBbTgrbsQSGa37bm0qliGYL8lpKfaViQydKisHVt9NMB2UHyQ9p eftsKeaLq45MZpqczoKQrZ66jEjxiHhn/yHIJ9RKIyDmB7sk5AsZxGcUOYXadkWAt8wL tObvyW/v5sb+720p+rUkatizW8NXJWaAVNnXh0tYvjKglTryCXCY07uXp/BLdLIzbSLX PGH1zhgqbD/HW/NJi5SuqYfklbKz+4rRRjS+siYry+K4XE+YBpLURs/39o41ImZlWgde FMKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=5f69AU45Mc43jUI52pxPbNIHBxHpq1Vs6IgV33oaybM=; fh=z8oYXPnno1GqglbVmfOQo1JrXHUZKms/94CPjhHVYFI=; b=oMo6rK8bspf3aVMog8B3o+7cEanT3kwpzuSqPH4cqNTm8Lk0VGeZAi9jrQwdNBXdVr PjaMtMGF1yIu/7UVgn7JMDTrYhbXk0qF5WF1SAm7V7ccf44jaep2ZTD/NvLotwmRD5J8 m3Z1uvaykEturd0Mp+jQRprezEA09vb+sBOl/EWAg2uyfFdUpjDsa1JRdbEd2Uxx0kcH 3jrhltPrL3yow4aF0YIE63vEGXKnzBcTOHKL2Saa/tEIDG2VxECc60z0YE2CL4Z15Fbi GyeioDkXaqBUVEje/MJisKLq6SjJsc4hyz6cjOjtdzaLLDIMrohYT8EeG6r9zakIr0jp K+tA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Mdtfh7xQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id u2-20020a170902e5c200b001cc2f9d6a66si1690445plf.514.2023.10.31.15.06.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Oct 2023 15:06:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Mdtfh7xQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id B307A8080C57; Tue, 31 Oct 2023 15:06:01 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344880AbjJaWFt (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 33 others); Tue, 31 Oct 2023 18:05:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229621AbjJaWFq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 31 Oct 2023 18:05:46 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D115EA for <linux-kernel@vger.kernel.org>; Tue, 31 Oct 2023 15:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698789944; x=1730325944; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=IwpVz6MF9Gm8aHgWudjf+PhbOFRizyKxWaZV8j9bj5E=; b=Mdtfh7xQZFWl3kjvRWGxNaRUXoj0eiRTfclxrBil5+/boL/OQPW4+17O rCXhVWPQ34QyEkLArNPDAMTDvKY2XmpsUXDy2/vtmiB33kybn1OEbI/jf 1JP/F6/7UAyta+6tY+H4nv2WCWJoa8oNU52HAj03+wHc89vEyda222Yq/ pKXtbVVTB2TjV7hw+cHfczYat0EMyhqjnuKT9/t7d6uxwBTNPqSwCAggx kwJC4LAkJnMP/KgiDZaOyAhbPg1QhwCyWcmTfTcyUWktzvEhirhMsNxmN hSHfdmqyywv+d26EdVmJptUINUFIiE9plswALXsvhFpD/nr2YobVLcoF5 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10880"; a="391251400" X-IronPort-AV: E=Sophos;i="6.03,266,1694761200"; d="scan'208";a="391251400" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2023 15:05:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.03,266,1694761200"; d="scan'208";a="8456911" Received: from agluck-desk3.sc.intel.com ([172.25.222.74]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2023 15:05:43 -0700 From: Tony Luck <tony.luck@intel.com> To: Fenghua Yu <fenghua.yu@intel.com>, Reinette Chatre <reinette.chatre@intel.com>, Peter Newman <peternewman@google.com>, x86@kernel.org Cc: Shaopeng Tan <tan.shaopeng@fujitsu.com>, James Morse <james.morse@arm.com>, Jamie Iles <quic_jiles@quicinc.com>, Babu Moger <babu.moger@amd.com>, Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org, patches@lists.linux.dev, Tony Luck <tony.luck@intel.com> Subject: [PATCH] x86/resctrl: Fix unused variable warning in cache_alloc_hsw_probe() Date: Tue, 31 Oct 2023 15:05:34 -0700 Message-ID: <20231031220534.37730-1-tony.luck@intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Tue, 31 Oct 2023 15:06:01 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781310405072899362 X-GMAIL-MSGID: 1781310405072899362 |
Series |
x86/resctrl: Fix unused variable warning in cache_alloc_hsw_probe()
|
|
Commit Message
Luck, Tony
Oct. 31, 2023, 10:05 p.m. UTC
In a "W=1" build gcc throws a warning:
arch/x86/kernel/cpu/resctrl/core.c: In function ‘cache_alloc_hsw_probe’:
arch/x86/kernel/cpu/resctrl/core.c:139:16: warning: variable ‘h’ set but not used
Fix by switching from rdmsr() to rdmsrl() using a single u64 argument
for the MSR value instead of the pair of u32 for the high and low
halves.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
This has been annoying me for a while as the only warning from the
resctrl code when building with W=1.
N.B. compile tested only. I don't have a Haswell system to check this works.
arch/x86/kernel/cpu/resctrl/core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Comments
On Tue, Oct 31, 2023 at 03:05:34PM -0700, Tony Luck wrote: > In a "W=1" build gcc throws a warning: > > arch/x86/kernel/cpu/resctrl/core.c: In function ‘cache_alloc_hsw_probe’: > arch/x86/kernel/cpu/resctrl/core.c:139:16: warning: variable ‘h’ set but not used > > Fix by switching from rdmsr() to rdmsrl() using a single u64 argument > for the MSR value instead of the pair of u32 for the high and low > halves. > > Signed-off-by: Tony Luck <tony.luck@intel.com> > --- > This has been annoying me for a while as the only warning from the > resctrl code when building with W=1. > > N.B. compile tested only. I don't have a Haswell system to check this works. > > arch/x86/kernel/cpu/resctrl/core.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 19e0681f0435..4084131d391d 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -136,15 +136,16 @@ static inline void cache_alloc_hsw_probe(void) > { > struct rdt_hw_resource *hw_res = &rdt_resources_all[RDT_RESOURCE_L3]; > struct rdt_resource *r = &hw_res->r_resctrl; > - u32 l, h, max_cbm = BIT_MASK(20) - 1; > + u32 max_cbm = BIT_MASK(20) - 1; > + u64 l3_cbm_0; > > if (wrmsr_safe(MSR_IA32_L3_CBM_BASE, max_cbm, 0)) > return; > > - rdmsr(MSR_IA32_L3_CBM_BASE, l, h); > + rdmsrl(MSR_IA32_L3_CBM_BASE, l3_cbm_0); > > /* If all the bits were set in MSR, return success */ > - if (l != max_cbm) > + if (l3_cbm_0 != max_cbm) > return; > > hw_res->num_closid = 4; No noticeable regressions on my Acer Aspire E15 (the laptop uses Intel Core i3 Haswell), thanks! Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
> No noticeable regressions on my Acer Aspire E15 (the laptop uses Intel Core > i3 Haswell), thanks! > > Tested-by: Bagas Sanjaya <bagasdotme@gmail.com> Thanks for reporting that you tested. I don't think a Haswell i3 gets as far as the piece of code that I changed. the wrmsr_safe() will return non-zero and the function returns before getting to the piece that I changed. -Tony
Hi Tony, On 10/31/23 17:05, Tony Luck wrote: > In a "W=1" build gcc throws a warning: > > arch/x86/kernel/cpu/resctrl/core.c: In function ‘cache_alloc_hsw_probe’: > arch/x86/kernel/cpu/resctrl/core.c:139:16: warning: variable ‘h’ set but not used > > Fix by switching from rdmsr() to rdmsrl() using a single u64 argument > for the MSR value instead of the pair of u32 for the high and low > halves. > > Signed-off-by: Tony Luck <tony.luck@intel.com> > --- > This has been annoying me for a while as the only warning from the > resctrl code when building with W=1. > > N.B. compile tested only. I don't have a Haswell system to check this works. > > arch/x86/kernel/cpu/resctrl/core.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c > index 19e0681f0435..4084131d391d 100644 > --- a/arch/x86/kernel/cpu/resctrl/core.c > +++ b/arch/x86/kernel/cpu/resctrl/core.c > @@ -136,15 +136,16 @@ static inline void cache_alloc_hsw_probe(void) > { > struct rdt_hw_resource *hw_res = &rdt_resources_all[RDT_RESOURCE_L3]; > struct rdt_resource *r = &hw_res->r_resctrl; > - u32 l, h, max_cbm = BIT_MASK(20) - 1; > + u32 max_cbm = BIT_MASK(20) - 1; > + u64 l3_cbm_0; > > if (wrmsr_safe(MSR_IA32_L3_CBM_BASE, max_cbm, 0)) > return; > > - rdmsr(MSR_IA32_L3_CBM_BASE, l, h); > + rdmsrl(MSR_IA32_L3_CBM_BASE, l3_cbm_0); You are writing 32 bit and reading 64 bit. Why don't you change both to 64 bit? > > /* If all the bits were set in MSR, return success */ > - if (l != max_cbm) > + if (l3_cbm_0 != max_cbm) > return; > > hw_res->num_closid = 4;
> > if (wrmsr_safe(MSR_IA32_L3_CBM_BASE, max_cbm, 0)) > > return; > > > > - rdmsr(MSR_IA32_L3_CBM_BASE, l, h); > > + rdmsrl(MSR_IA32_L3_CBM_BASE, l3_cbm_0); > > You are writing 32 bit and reading 64 bit. Why don't you change both to 64 > bit? wrmsr_safe() writes all 64-bits ... just gets those bits as a pair of 32-bit arguments for the low and high halves. I could switch that to wrmsrl_safe() and change max_cbm to be "u64" to make write & read match. Would that be better? -Tony
On 11/1/23 15:33, Luck, Tony wrote: >>> if (wrmsr_safe(MSR_IA32_L3_CBM_BASE, max_cbm, 0)) >>> return; >>> >>> - rdmsr(MSR_IA32_L3_CBM_BASE, l, h); >>> + rdmsrl(MSR_IA32_L3_CBM_BASE, l3_cbm_0); >> >> You are writing 32 bit and reading 64 bit. Why don't you change both to 64 >> bit? > > wrmsr_safe() writes all 64-bits ... just gets those bits as a pair > of 32-bit arguments for the low and high halves. > > I could switch that to wrmsrl_safe() and change max_cbm to be "u64" > to make write & read match. Would that be better? Yes. That is better.
diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c index 19e0681f0435..4084131d391d 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -136,15 +136,16 @@ static inline void cache_alloc_hsw_probe(void) { struct rdt_hw_resource *hw_res = &rdt_resources_all[RDT_RESOURCE_L3]; struct rdt_resource *r = &hw_res->r_resctrl; - u32 l, h, max_cbm = BIT_MASK(20) - 1; + u32 max_cbm = BIT_MASK(20) - 1; + u64 l3_cbm_0; if (wrmsr_safe(MSR_IA32_L3_CBM_BASE, max_cbm, 0)) return; - rdmsr(MSR_IA32_L3_CBM_BASE, l, h); + rdmsrl(MSR_IA32_L3_CBM_BASE, l3_cbm_0); /* If all the bits were set in MSR, return success */ - if (l != max_cbm) + if (l3_cbm_0 != max_cbm) return; hw_res->num_closid = 4;