Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp5365008pxu; Wed, 21 Oct 2020 23:31:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJynN0wi6UIodPAzLLVrOYV59ATc/aSVg7xy3Q2fvYm5c7/Qgyt8mdT9pNPEugxxjAE4xsHo X-Received: by 2002:a17:906:b1c9:: with SMTP id bv9mr857794ejb.495.1603348315228; Wed, 21 Oct 2020 23:31:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603348315; cv=none; d=google.com; s=arc-20160816; b=aGvIbKD55u6EitpO63WDGS1ENcv39NuwiWQ1Ui8ujBgaCqQf7P7cr+Z1J1JS8m4IXw TQ5c5sIh4zLr2y8eoyzof89NZrnxmp3gkIKNJuGBEl8i68xNhEt7n9fAgWBZxjTlZuwp R9uGL8+A7vwnPle4AN4wXgPstk+ZpL+QmxZZv388S5xaUhGdn50DA4zOdDt7YEER0g4D ZlR3HKh8GJFg/76xFgkylebEdCmmH3A4z5Wh6lRHBPLyMkQJYIDWyCq/tC9BQ+0ekSp5 N2p9AQXeuPrvLezJ4qV1hsB+D6qANEMKzy8MyhwcyOkg+FmhOMCBFElUpNWIjdxtCQw+ J4pw== 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=dSLCOYQavb8mUABw/L3Y04nU9NdxNUUDGRxnLFNNP50=; b=ZlUkKKT/AxbrLqgauIUXKK7q+6s3/WF2ruRkH0ktvrGy1K2jN4C54HkAaFYBjef0+m STqiXWWSe0Mtoq/3qI6dkgQLd/Hm+XSdy5PIobwcaaIcFFfYAtJZEJoao8C2jwO9/3mw hi8lfBuXNdxBDM9NKzXD/duI5luCs7SAW3mmQ0AQ+N5oRSglRfk0Nak6YiS7zlUB/lW1 rdbUPDIJ1E2bmZZc26vhzwHBsjok+tfOqAbjWmFSwMnya49kaKoUaywACLmK/x1MeooK Kl+y44Z0XNk9BpmBJ0LVqoFWrm+2NBTkKzWRHu8mpJzwQEEW9X/jDNTkfmVImkNBHgSh Knfg== 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 h10si377455edr.423.2020.10.21.23.31.33; Wed, 21 Oct 2020 23:31:55 -0700 (PDT) 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 S2503537AbgJUSMD (ORCPT + 99 others); Wed, 21 Oct 2020 14:12:03 -0400 Received: from cloudserver094114.home.pl ([79.96.170.134]:48164 "EHLO cloudserver094114.home.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2438246AbgJUSMD (ORCPT ); Wed, 21 Oct 2020 14:12:03 -0400 Received: from 89-77-60-66.dynamic.chello.pl (89.77.60.66) (HELO kreacher.localnet) by serwer1319399.home.pl (79.96.170.134) with SMTP (IdeaSmtpServer 0.83.491) id 2f19e6705ded5679; Wed, 21 Oct 2020 20:12:00 +0200 From: "Rafael J. Wysocki" To: Peter Zijlstra Cc: Julia Lawall , Mel Gorman , Ingo Molnar , kernel-janitors@vger.kernel.org, Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org, Valentin Schneider , Gilles Muller , viresh.kumar@linaro.org, srinivas.pandruvada@linux.intel.com Subject: Re: [PATCH] sched/fair: check for idle core Date: Wed, 21 Oct 2020 20:11:59 +0200 Message-ID: <6145907.dAfbsivgMF@kreacher> In-Reply-To: <20201021131026.GY2651@hirez.programming.kicks-ass.net> References: <1603211879-1064-1-git-send-email-Julia.Lawall@inria.fr> <20201021121950.GF2628@hirez.programming.kicks-ass.net> <20201021131026.GY2651@hirez.programming.kicks-ass.net> 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 On Wednesday, October 21, 2020 3:10:26 PM CEST Peter Zijlstra wrote: > On Wed, Oct 21, 2020 at 02:19:50PM +0200, Peter Zijlstra wrote: > > On Wed, Oct 21, 2020 at 01:56:55PM +0200, Julia Lawall wrote: > > > Prior to 5.8, my machine was using intel_pstate and had few background > > > tasks. Thus the problem wasn't visible in practice. Starting with 5.8 > > > the kernel decided that intel_cpufreq would be more appropriate, which > > > introduced kworkers every 0.004 seconds on all cores. > > > > That still doesn't make any sense. Are you running the legacy on-demand > > thing or something? > > > > Rafael, Srinivas, Viresh, how come it defaults to that? > > Does we want something like this? > > --- > arch/x86/configs/i386_defconfig | 3 +-- > arch/x86/configs/x86_64_defconfig | 3 +-- > drivers/cpufreq/Kconfig | 7 +++++-- > 3 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig > index 78210793d357..c343ad459737 100644 > --- a/arch/x86/configs/i386_defconfig > +++ b/arch/x86/configs/i386_defconfig > @@ -41,8 +41,7 @@ CONFIG_PM_DEBUG=y > CONFIG_PM_TRACE_RTC=y > CONFIG_ACPI_DOCK=y > CONFIG_ACPI_BGRT=y > -CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > -CONFIG_CPU_FREQ_GOV_ONDEMAND=y > +CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y > CONFIG_X86_ACPI_CPUFREQ=y > CONFIG_EFI_VARS=y > CONFIG_KPROBES=y > diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig > index 9936528e1939..23e1ea85c1ec 100644 > --- a/arch/x86/configs/x86_64_defconfig > +++ b/arch/x86/configs/x86_64_defconfig > @@ -38,8 +38,7 @@ CONFIG_PM_DEBUG=y > CONFIG_PM_TRACE_RTC=y > CONFIG_ACPI_DOCK=y > CONFIG_ACPI_BGRT=y > -CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > -CONFIG_CPU_FREQ_GOV_ONDEMAND=y > +CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y > CONFIG_X86_ACPI_CPUFREQ=y > CONFIG_IA32_EMULATION=y > CONFIG_EFI_VARS=y > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig > index 2c7171e0b001..8dfca6e9b836 100644 > --- a/drivers/cpufreq/Kconfig > +++ b/drivers/cpufreq/Kconfig > @@ -37,8 +37,7 @@ config CPU_FREQ_STAT > choice > prompt "Default CPUFreq governor" > default CPU_FREQ_DEFAULT_GOV_USERSPACE if ARM_SA1100_CPUFREQ || ARM_SA1110_CPUFREQ > - default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if ARM64 || ARM > - default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if X86_INTEL_PSTATE && SMP > + default CPU_FREQ_DEFAULT_GOV_SCHEDUTIL if SMP > default CPU_FREQ_DEFAULT_GOV_PERFORMANCE > help > This option sets which CPUFreq governor shall be loaded at > @@ -71,6 +70,7 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE > > config CPU_FREQ_DEFAULT_GOV_ONDEMAND > bool "ondemand" > + depends on !SMP > select CPU_FREQ_GOV_ONDEMAND > select CPU_FREQ_GOV_PERFORMANCE > help > @@ -83,6 +83,7 @@ config CPU_FREQ_DEFAULT_GOV_ONDEMAND > > config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE > bool "conservative" > + depends on !SMP > select CPU_FREQ_GOV_CONSERVATIVE > select CPU_FREQ_GOV_PERFORMANCE > help The changes above should work. > @@ -144,6 +145,7 @@ config CPU_FREQ_GOV_USERSPACE > > config CPU_FREQ_GOV_ONDEMAND > tristate "'ondemand' cpufreq policy governor" > + depends on !SMP But I don't think that we can do this and the one below. > select CPU_FREQ_GOV_COMMON > help > 'ondemand' - This driver adds a dynamic cpufreq policy governor. > @@ -163,6 +165,7 @@ config CPU_FREQ_GOV_ONDEMAND > config CPU_FREQ_GOV_CONSERVATIVE > tristate "'conservative' cpufreq governor" > depends on CPU_FREQ > + depends on !SMP > select CPU_FREQ_GOV_COMMON > help > 'conservative' - this driver is rather similar to the 'ondemand' >