Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1310915pxb; Thu, 4 Feb 2021 09:41:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJwBZtUBGHGScpc2PYWQ2tRB+P8XzgLb0rc874tdvJGEjlE1ii/emx/74iUQto0zx4NVyuuK X-Received: by 2002:a17:906:69c2:: with SMTP id g2mr192422ejs.249.1612460469646; Thu, 04 Feb 2021 09:41:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612460469; cv=none; d=google.com; s=arc-20160816; b=DXYNaosl96V7HD/bp7qfC6akhaPvmALmaknsnx6P/Hqw4W+PHqHqhGtlFyNzMk5UTH XQlzPZcHdNOlKUmz0yEes+MINsO+kyqIOlZIVkez37OBQSTZhogoIPrf8+0YDhXq+a/1 nvVgL9KDdUG1jzHKj91eFZzBC8P04ksS5SbJ/fHxaF+qqg7k9lfNGIMZmT582H17p+Gc b+sYIbROG4BYaEUqkOECIOmMToWhKp68QWYgk1isJ5YI2rFMwkO52vzpoujdyzibcsbe /VPHBosXv4qRiwFUrbUS0J5DE0Bc59Y2oYLTTiN7GX/XOMtp5HePvklbpxZDV2duO35p Of+Q== 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 :references:in-reply-to:message-id:date:subject:cc:to:from; bh=Eu1d7G1rkNmWSut0vcgbpuik73v3h3inmTtrCVgrBn8=; b=RgYZN/vFpCaza9CF5szS+2kOy2RTXpVo/bu2w6M6U0rKqI9sFn1JPEEpVZPW8kKUx8 zqII+xpdgNH372dtm3XCc+XwsI3hHw2A4OmQRuZT0tRL5BmPyu2xdaFCUB6F0PPale9i 2ximSN5zzDD/iylseWSXGqE2kqIBftZ4SKDhBvxGR8Ip5QYbCGQQ52bujVLd+6v+0NdW +AVEUJkvKIanBZc/tzJru6aPkEMTOpZ3RvVs0m3Ewm6zD06rbHqzDzd4ngRUltOhQDWk OQV8cOvOgtAlS8gG25sCbnZtzjKMivuA3osp3HypR48yHHH0LaYX4gF87dTvzt9U9nd3 ntOA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c16si3757282ejm.289.2021.02.04.09.40.44; Thu, 04 Feb 2021 09:41:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238677AbhBDRiQ (ORCPT + 99 others); Thu, 4 Feb 2021 12:38:16 -0500 Received: from cloudserver094114.home.pl ([79.96.170.134]:53272 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238634AbhBDRgL (ORCPT ); Thu, 4 Feb 2021 12:36:11 -0500 Received: from 89-64-81-64.dynamic.chello.pl (89.64.81.64) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.537) id de86f543d15ab5d9; Thu, 4 Feb 2021 18:34:58 +0100 From: "Rafael J. Wysocki" To: Linux PM Cc: LKML , Linux ACPI , Peter Zijlstra , Srinivas Pandruvada , Viresh Kumar , Giovanni Gherdovich , Mel Gorman , Michael Larabel , Juri Lelli , Vincent Guittot Subject: [PATCH v1 2/2] cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there Date: Thu, 04 Feb 2021 18:34:32 +0100 Message-ID: <9510730.kuOQ4KzHjt@kreacher> In-Reply-To: <13690581.X0sz4iL7V8@kreacher> References: <13690581.X0sz4iL7V8@kreacher> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Rafael J. Wysocki If the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale-invariance code is higher than the one corresponding to the cpuinfo.max_freq value coming from the acpi_cpufreq driver, the scale-invariant utilization falls below 100% even if the CPU runs at cpuinfo.max_freq or slightly faster, which causes the schedutil governor to select a frequency below cpuinfo.max_freq. That frequency corresponds to a frequency table entry below the maximum performance level necessary to get to the "boost" range of CPU frequencies which prevents "boost" frequencies from being used in some workloads. While this issue is related to scale-invariance, it may be amplified by commit db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") from the 5.10 development cycle which made it extremely easy to default to schedutil even if the preferred driver is acpi_cpufreq as long as intel_pstate is built too, because the mere presence of the latter effectively removes the ondemand governor from the defaults. Distro kernels are likely to include both intel_pstate and acpi_cpufreq on x86, so their users who cannot use intel_pstate or choose to use acpi_cpufreq may easily be affectecd by this issue. If CPPC is available, it can be used to address this issue by extending the frequency tables created by acpi_cpufreq to cover the entire available frequency range (including "boost" frequencies) for each CPU, but if CPPC is not there, acpi_cpufreq has no idea what the maximum "boost" frequency is and the frequency tables created by it cannot be extended in a meaningful way, so in that case make it ask the arch scale-invariance code to to use the "nominal" performance level for CPU utilization scaling in order to avoid the issue at hand. Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") Signed-off-by: Rafael J. Wysocki --- arch/x86/kernel/smpboot.c | 1 + drivers/cpufreq/acpi-cpufreq.c | 8 ++++++++ 2 files changed, 9 insertions(+) Index: linux-pm/drivers/cpufreq/acpi-cpufreq.c =================================================================== --- linux-pm.orig/drivers/cpufreq/acpi-cpufreq.c +++ linux-pm/drivers/cpufreq/acpi-cpufreq.c @@ -806,6 +806,14 @@ static int acpi_cpufreq_cpu_init(struct state_count++; valid_states++; data->first_perf_state = valid_states; + } else { + /* + * If the maximum "boost" frequency is unknown, ask the arch + * scale-invariance code to use the "nominal" performance for + * CPU utilization scaling so as to prevent the schedutil + * governor from selecting inadequate CPU frequencies. + */ + arch_set_max_freq_ratio(true); } freq_table = kcalloc(state_count, sizeof(*freq_table), GFP_KERNEL); Index: linux-pm/arch/x86/kernel/smpboot.c =================================================================== --- linux-pm.orig/arch/x86/kernel/smpboot.c +++ linux-pm/arch/x86/kernel/smpboot.c @@ -1833,6 +1833,7 @@ void arch_set_max_freq_ratio(bool turbo_ arch_max_freq_ratio = turbo_disabled ? SCHED_CAPACITY_SCALE : arch_turbo_freq_ratio; } +EXPORT_SYMBOL_GPL(arch_set_max_freq_ratio); static bool turbo_disabled(void) {