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=-5.2 required=3.0 tests=BAYES_00, 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 4CDD5C388F7 for ; Tue, 10 Nov 2020 14:05:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DEB3220809 for ; Tue, 10 Nov 2020 14:05:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730572AbgKJOFL (ORCPT ); Tue, 10 Nov 2020 09:05:11 -0500 Received: from outbound-smtp34.blacknight.com ([46.22.139.253]:54495 "EHLO outbound-smtp34.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729898AbgKJOFL (ORCPT ); Tue, 10 Nov 2020 09:05:11 -0500 Received: from mail.blacknight.com (pemlinmail02.blacknight.ie [81.17.254.11]) by outbound-smtp34.blacknight.com (Postfix) with ESMTPS id A1D362037 for ; Tue, 10 Nov 2020 14:05:09 +0000 (GMT) Received: (qmail 25852 invoked from network); 10 Nov 2020 14:05:09 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 10 Nov 2020 14:05:09 -0000 Date: Tue, 10 Nov 2020 14:05:07 +0000 From: Mel Gorman To: Vincent Guittot Cc: Phil Auld , Peter Puhov , linux-kernel , Robert Foley , Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Jirka Hladky Subject: Re: [PATCH v1] sched/fair: update_pick_idlest() Select group with lowest group_util when idle_cpus are equal Message-ID: <20201110140507.GI3371@techsingularity.net> References: <20201102105043.GB3371@techsingularity.net> <20201102144418.GB154641@lorien.usersys.redhat.com> <20201104094205.GI3306@suse.de> <20201106120303.GE3371@techsingularity.net> <20201106160010.GF3371@techsingularity.net> <20201109152411.GA610888@lorien.usersys.redhat.com> <20201109153815.GH3371@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 09, 2020 at 04:49:07PM +0100, Vincent Guittot wrote: > > This aspect is somewhat critical because the patches affect CPU > > selection. If a mostly idle CPU is used due to spreading load wider, > > it can take longer to ramp up to the highest frequency. It can be a > > dominating factor and may account for some of the differences. > > I agree but that also highlights that the problem comes from frequency > selection more than task placement. In such a case, instead of trying > to bias task placement to compensate for wrong freq selection, we > should look at the freq selection itself. Not sure if it's the case > but it's worth identifying if perf regression comes from task > placement and data locality or from freq selection > That's a fair point although it's worth noting the biasing the freq selection itself means that schedutil needs to become the default which is not quite there yet. Otherwise, the machine is often relying on firmware to give hints as to how quickly it should ramp up or per-driver hacks which is the road to hell. > > > > Generally my tests are not based on the performance governor because a) > > it's not a universal win and b) the powersave/ondemand govenors should > > be able to function reasonably well. For short-lived workloads it may > > not matter but ultimately schedutil should be good enough that it can > > Yeah, schedutil should be able to manage this. But there is another > place which impacts benchmark which are based on a lot of fork/exec : > the initial value of task's PELT signal. Current implementation tries > to accommodate both perf and embedded system but might fail to satisfy > any of them at the end. > Quite likely. Assuming schedutil gets the default, it may be necessary to either have a tunable or a kconfig that affects the initial PELT signal as to whether it should start low and ramp up, pick a midpoint or start high and scale down. -- Mel Gorman SUSE Labs