Message ID | 20230303041411.3161780-1-srinivas.pandruvada@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp227216wrd; Thu, 2 Mar 2023 20:56:52 -0800 (PST) X-Google-Smtp-Source: AK7set8yMVE667j1H0kmw3bKbTOi3e0xvEUCLbPgn8mQpgnrBhPAZoHd/up1FUwadGFieO/iru2n X-Received: by 2002:a05:6a20:1a87:b0:cd:8854:4de8 with SMTP id ci7-20020a056a201a8700b000cd88544de8mr897505pzb.50.1677819411742; Thu, 02 Mar 2023 20:56:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677819411; cv=none; d=google.com; s=arc-20160816; b=f87CMa6lca3Vvgj2DIJzNEQ+UEsxYloCaQ2KPBPzPS/+waIbhcAcPwpo07CnyWYINs bipGH9allp2yLQ3eQC2munMRLKCE1whsYecqhW1gVeY193Ubv2NEudF1vFb5IWSm5TB1 xXftrNU45buybdCaQHynBKyP7hLPSJWIYUS5qZnq+NXRwycxD5koK1GjVKc7YnWQjpqe ry68JbJWB8wgY19o0f2sGJUh6yucT8FycmmipHSp8gY5re8gfkIvH8Ep1tQNSFBTpulL d4Wa2DtfKZQ4462WoBYTpUetmqml5KkOhJG40j/MHaeYQSlzHvpCwOuhIfLodGK8BOO9 9SVg== 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=/9vgJHVUCW0qQ7jjPWt1fBug7D1wcYhdiY/x1+SesM4=; b=ra4Xy86cZg1tH2eH0Ahb4bW3zNviFbfmYCsKLy++Qi+IdICpyi9IPkcO4LPoiLDvqc Om/HcNd7tp0HJkTWIa/GEGCxCr8Z861jRzh1aZ+/zZPvFvmBG8xSBBDuu3Zvr0mUWLO8 FTDL1TEOc+ytCar8od67xqkAXLyO/fc0TY6yp4oA5MN2cZ0QpQS2vuGvme5cmRcxBVhf VfNdOe8wWfcHIqcWooBad44NXXfIlhssYUMVNy+KxNgQP7AZE/fKMk0dWrOmsc8DcpLb mF5N2y19qWNDzlIUqA+S3U4SV8/H8KyxSmpfaT4+qbbZSfdRq4gqEjCaHD+Wz6bNYLyU 76Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Bl0Lg5MR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p12-20020a631e4c000000b004cc96852d19si1254714pgm.63.2023.03.02.20.56.38; Thu, 02 Mar 2023 20:56:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Bl0Lg5MR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229551AbjCCEOT (ORCPT <rfc822;davidbtadokoro@gmail.com> + 99 others); Thu, 2 Mar 2023 23:14:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbjCCEOR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Mar 2023 23:14:17 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36FEA12BE6; Thu, 2 Mar 2023 20:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1677816857; x=1709352857; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=vF/1poQJ5i2/fALYadh5wXENB15OfhGT7T0JvZIYi0I=; b=Bl0Lg5MRLFrwskFU/gAuNLdwv4PpTyiVrjfu3N5Zdxid4A2tB92dYd29 RYXmVbhLiibvpaMQ8ha33UxEliZlZge5KZJS1W8cR0n4DsuUOpuZhEaMG 3y4hMbWU2nC0xjisZdfqlK74peb/RVI7xKAQlDFrzCdAcdppr7G9cP9GZ DLpsIoNwFkTCeoe29VOWAIvf9Lv6nm/W6KYSvdNSImFLAj69VzRAkYfJy 5Kk73rkEoXJkShsKGkBWDxJsKIhD+XCTi7XgDMkX+FX9lVP0rRiVurabW D9MjJp3QJfPDwzwz159d6KSDp0C0kP/bRPhyBD7vNZSM//LkOzorTMNgT A==; X-IronPort-AV: E=McAfee;i="6500,9779,10637"; a="333671402" X-IronPort-AV: E=Sophos;i="5.98,229,1673942400"; d="scan'208";a="333671402" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Mar 2023 20:14:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10637"; a="744119122" X-IronPort-AV: E=Sophos;i="5.98,229,1673942400"; d="scan'208";a="744119122" Received: from spandruv-desk.jf.intel.com ([10.54.75.8]) by fmsmga004.fm.intel.com with ESMTP; 02 Mar 2023 20:14:16 -0800 From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> To: rafael@kernel.org, lenb@kernel.org, viresh.kumar@linaro.org Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Subject: [PATCH] cpufreq: intel_pstate: Enable HWP IO boost for all servers Date: Thu, 2 Mar 2023 20:14:11 -0800 Message-Id: <20230303041411.3161780-1-srinivas.pandruvada@linux.intel.com> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759321167662494261?= X-GMAIL-MSGID: =?utf-8?q?1759321167662494261?= |
Series |
cpufreq: intel_pstate: Enable HWP IO boost for all servers
|
|
Commit Message
srinivas pandruvada
March 3, 2023, 4:14 a.m. UTC
The HWP IO boost results in slight improvements for IO performance on
both Ice Lake and Sapphire Rapid servers.
Currently there is a CPU model check for Skylake desktop and server along
with the ACPI PM profile for performance and enterprise servers to enable
IO boost.
Remove the CPU model check, so that all current server models enable HWP
IO boost by default.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
drivers/cpufreq/intel_pstate.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
Comments
On Fri, Mar 3, 2023 at 5:14 AM Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote: > > The HWP IO boost results in slight improvements for IO performance on > both Ice Lake and Sapphire Rapid servers. > > Currently there is a CPU model check for Skylake desktop and server along > with the ACPI PM profile for performance and enterprise servers to enable > IO boost. > > Remove the CPU model check, so that all current server models enable HWP > IO boost by default. > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > --- > drivers/cpufreq/intel_pstate.c | 11 +---------- > 1 file changed, 1 insertion(+), 10 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index cb4beec27555..8edbc0856892 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -2384,12 +2384,6 @@ static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[] = { > {} > }; > > -static const struct x86_cpu_id intel_pstate_hwp_boost_ids[] = { > - X86_MATCH(SKYLAKE_X, core_funcs), > - X86_MATCH(SKYLAKE, core_funcs), > - {} > -}; > - > static int intel_pstate_init_cpu(unsigned int cpunum) > { > struct cpudata *cpu; > @@ -2408,12 +2402,9 @@ static int intel_pstate_init_cpu(unsigned int cpunum) > cpu->epp_default = -EINVAL; > > if (hwp_active) { > - const struct x86_cpu_id *id; > - > intel_pstate_hwp_enable(cpu); > > - id = x86_match_cpu(intel_pstate_hwp_boost_ids); > - if (id && intel_pstate_acpi_pm_profile_server()) > + if (intel_pstate_acpi_pm_profile_server()) > hwp_boost = true; > } > } else if (hwp_active) { > -- Applied as 6.4 material, thanks!
On Thu, 2023-03-02 at 20:14 -0800, Srinivas Pandruvada wrote: > The HWP IO boost results in slight improvements for IO performance on > both Ice Lake and Sapphire Rapid servers. > > Currently there is a CPU model check for Skylake desktop and server along > with the ACPI PM profile for performance and enterprise servers to enable > IO boost. > > Remove the CPU model check, so that all current server models enable HWP > IO boost by default. > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > --- > drivers/cpufreq/intel_pstate.c | 11 +---------- > 1 file changed, 1 insertion(+), 10 deletions(-) > > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c > index cb4beec27555..8edbc0856892 100644 > --- a/drivers/cpufreq/intel_pstate.c > +++ b/drivers/cpufreq/intel_pstate.c > @@ -2384,12 +2384,6 @@ static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[] = { > {} > }; > > -static const struct x86_cpu_id intel_pstate_hwp_boost_ids[] = { > - X86_MATCH(SKYLAKE_X, core_funcs), > - X86_MATCH(SKYLAKE, core_funcs), > - {} > -}; > - > static int intel_pstate_init_cpu(unsigned int cpunum) > { > struct cpudata *cpu; > @@ -2408,12 +2402,9 @@ static int intel_pstate_init_cpu(unsigned int cpunum) > cpu->epp_default = -EINVAL; > > if (hwp_active) { > - const struct x86_cpu_id *id; > - > intel_pstate_hwp_enable(cpu); > > - id = x86_match_cpu(intel_pstate_hwp_boost_ids); > - if (id && intel_pstate_acpi_pm_profile_server()) > + if (intel_pstate_acpi_pm_profile_server()) > hwp_boost = true; > } > } else if (hwp_active) { Hello Srinivas, Good catch. We've had HWP IO Boost in the kernel for a while now but we weren't enabling on most of the modern CPUs... This fixes it. One thing though: I've the impression that HWP IO Boost depends on having per-core p-states -- otherwise you'll be boosting up and down the entire machine instead of just the one core waking up from IO. Enabling the feature on all machines with the ACPI PM server profile would force it also where per-core p-states aren't available. Would you agree with this assessment? Do I correctly understand the reason why per-core p-states are needed here? I remember you mentioned the the dependency on per-core p-states in the cover letter from the HWP IO Boost submission in 2018 https://lore.kernel.org/lkml/20180605214242.62156-1-srinivas.pandruvada@linux.intel.com/ I think there's a tradeoff here. Up until this patch, we forgot to enable the feature on four generations of Intel CPUs. That's a lot of lost performance; thanks to this patch it won't happen ever again, because nobody will have to update the model list at every new CPU release. On the other side, there may be some penalty for machines that: - have HWP - don't have per-core p-states I don't know how large that interesection is, or how big the penalty. Giovanni
On Mon, 2023-03-20 at 18:03 +0100, Giovanni Gherdovich wrote: > On Thu, 2023-03-02 at 20:14 -0800, Srinivas Pandruvada wrote: > ... Hi Giovanni, > Hello Srinivas, > > Good catch. We've had HWP IO Boost in the kernel for a while now but > we > weren't enabling on most of the modern CPUs... This fixes it. > > One thing though: I've the impression that HWP IO Boost depends on > having > per-core p-states -- otherwise you'll be boosting up and down the > entire machine > instead of just the one core waking up from IO. > Enabling the feature on all machines with the ACPI PM server profile > would > force it also where per-core p-states aren't available. This feature only exists on HWP systems. There are no HWP systems without per core P-states. Here we are enabling for performance and enterprise servers only. > > Would you agree with this assessment? > Do I correctly understand the reason why per-core p-states are needed > here? This problem with IO will be more pronounced in per-core P-states systems as it will not be influenced by other cores. But even if non per-core systems if other cores are idle or lightly loaded, the same problem can occur. But I don't have data on such systems. > > I remember you mentioned the the dependency on per-core p-states in > the cover > letter from the HWP IO Boost submission in 2018 > https://lore.kernel.org/lkml/20180605214242.62156-1-srinivas.pandruvada@linux.intel.com/ > > I think there's a tradeoff here. Up until this patch, we forgot to > enable the > feature on four generations of Intel CPUs. That's a lot of lost > performance; > thanks to this patch it won't happen ever again, because nobody will > have to > update the model list at every new CPU release. > CPU model updates always gets missed and also misses testing opportunity. > On the other side, there may be some penalty for machines that: > - have HWP > - don't have per-core p-states > I don't know how large that interesection is, or how big the penalty. > Thanks, Srinivas > > Giovanni >
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index cb4beec27555..8edbc0856892 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -2384,12 +2384,6 @@ static const struct x86_cpu_id intel_pstate_cpu_ee_disable_ids[] = { {} }; -static const struct x86_cpu_id intel_pstate_hwp_boost_ids[] = { - X86_MATCH(SKYLAKE_X, core_funcs), - X86_MATCH(SKYLAKE, core_funcs), - {} -}; - static int intel_pstate_init_cpu(unsigned int cpunum) { struct cpudata *cpu; @@ -2408,12 +2402,9 @@ static int intel_pstate_init_cpu(unsigned int cpunum) cpu->epp_default = -EINVAL; if (hwp_active) { - const struct x86_cpu_id *id; - intel_pstate_hwp_enable(cpu); - id = x86_match_cpu(intel_pstate_hwp_boost_ids); - if (id && intel_pstate_acpi_pm_profile_server()) + if (intel_pstate_acpi_pm_profile_server()) hwp_boost = true; } } else if (hwp_active) {