From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AB6BC43215 for ; Mon, 25 Nov 2019 09:16:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6D6B020815 for ; Mon, 25 Nov 2019 09:16:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727198AbfKYJQm (ORCPT ); Mon, 25 Nov 2019 04:16:42 -0500 Received: from outbound-smtp30.blacknight.com ([81.17.249.61]:58909 "EHLO outbound-smtp30.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727051AbfKYJQm (ORCPT ); Mon, 25 Nov 2019 04:16:42 -0500 Received: from mail.blacknight.com (unknown [81.17.254.17]) by outbound-smtp30.blacknight.com (Postfix) with ESMTPS id E0CBFD072E for ; Mon, 25 Nov 2019 09:16:39 +0000 (GMT) Received: (qmail 28355 invoked from network); 25 Nov 2019 09:16:39 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.18.57]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 25 Nov 2019 09:16:39 -0000 Date: Mon, 25 Nov 2019 09:16:37 +0000 From: Mel Gorman To: Doug Smythies Cc: 'Giovanni Gherdovich' , 'Srinivas Pandruvada' , 'Thomas Gleixner' , 'Ingo Molnar' , 'Peter Zijlstra' , 'Borislav Petkov' , 'Len Brown' , "'Rafael J . Wysocki'" , x86@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, 'Matt Fleming' , 'Viresh Kumar' , 'Juri Lelli' , 'Paul Turner' , 'Vincent Guittot' , 'Quentin Perret' , 'Dietmar Eggemann' Subject: Re: [PATCH v4 1/6] x86,sched: Add support for frequency invariance Message-ID: <20191125091637.GB3016@techsingularity.net> References: <20191113124654.18122-1-ggherdovich@suse.cz> <20191113124654.18122-2-ggherdovich@suse.cz> <000001d5a29b$c944fd70$5bcef850$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <000001d5a29b$c944fd70$5bcef850$@net> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 23, 2019 at 11:49:57PM -0800, Doug Smythies wrote: > Hi all, > > The address list here is likely incorrect, > and this e-mail is really about a kernel 5.4 > bisected regression. > > It had been since mid September, and kernel 5.3-rc8 since > I had tried this, so I wanted to try it again. Call it due diligence. > I focused on my own version of the "gitsource" test. > > Kernel 5.4-rc8 (as a baseline reference). > > My results were extremely surprising. > > As it turns out, at least on my test computer, both the > acpi-cpufreq and intel_cpufreq CPU frequency scaling drivers > using the schedutil governor are broken. For the tests that > I ran, there is negligible difference between them and the > performance governor. So, one might argue that they are not > broken, but rather working incredibly well, which if true > then this patch is no longer needed. > I don't think that is necessarily fair. It still makes sense that the "size" of a task is independent of the frequency the CPU is running at for load balancing decisions and should be merged on that basis alone. If the scheduler made perfect decisions on task location then there would be negligible difference between ondemand (or powersave if intel_pstate) and performance governor too. cpufreq tends to be more noticable under the current implementation as tasks are a lot more mobile than they need to be for basic workloads. -- Mel Gorman SUSE Labs