Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp814622imm; Thu, 4 Oct 2018 03:56:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV60CH1p991U6yedi6B7Rq1N9PL9cmlhDOXEu2LYUNH8L168O1abotpf+rPru/Aj0nFD7zSW2 X-Received: by 2002:a17:902:3041:: with SMTP id u59-v6mr5918919plb.99.1538650603984; Thu, 04 Oct 2018 03:56:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538650603; cv=none; d=google.com; s=arc-20160816; b=aUUYwEQ+ve45FsLKxG8F24XID9IvNpt8eNI7ymb3eLhjFC7NMlu8jJPhJcHYfTe1NT 8lSHEcL0T80tVUZ5Xlsb0jsLlp5Dr+BMS68FlRhNsdYmEXj0bmlLUIK0By9EJtyPdjBR fi/efezt8BnRZlDeAxKhnrWVoSLOhAeuFbLLwMaMitrQfQEQHlh6i+DNqupkoZXV24q7 uOUtpNcVr+pcWWRuobwKd3reDxgF+j3THSgbh8ja1Ch4UgaLtdWpxSGJV7pXR9PQZmf9 gHAAyaOihLjjbzfqkTDpBlDZLqu0NM3qHoK586xQjdwAEgPdeUNGnd0ndms0Qc9FpuiO XgQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=uk9/+Rux2h0eMgBe1OnQ6iheLXgx5sSN9B1amX2CG1E=; b=rOedAj/shaXgpbflgQ04aNGnN4H9s1fhRWPTvPIcoCN/h9TALgwBmbQyToWevhM2ON iFINmudIdziR1UiAMT0OMAqEE5a/tUrZYAQ9mOOHsibrMnoSUd6bog+55tFcbVm0oSF1 TSIeAzEBAlN/jbA4iGAnC1Y0vITaSWSJBbu/qRntk0UXQs5+suH/k1v5R05dd3l5VJaL E/t5AQUI508bL+JyiCeXFNgX8bV+Z6JajZhHEHOxd7DQFTu4yXD8vKy1GleEMKCixaDl nt1DwFdhpTT4j5QN6l7l1kT1hHjTaNyw4hzaEb6DHfxBuzfHzBD+snwy9Nqa9Q0meXRr ORIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=TUNeBo5W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n74-v6si4971151pfj.30.2018.10.04.03.56.27; Thu, 04 Oct 2018 03:56:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=TUNeBo5W; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727406AbeJDRs5 (ORCPT + 99 others); Thu, 4 Oct 2018 13:48:57 -0400 Received: from merlin.infradead.org ([205.233.59.134]:52902 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727109AbeJDRs5 (ORCPT ); Thu, 4 Oct 2018 13:48:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uk9/+Rux2h0eMgBe1OnQ6iheLXgx5sSN9B1amX2CG1E=; b=TUNeBo5W25cSVrq/7ZvDZmA1v pIwbacZSzQzPvPaY9QGWca8qWuhzKGwLvV4mtocu3uxbkVoP46Vh43Ql5Tccnj/Nkce4OqIn4EjoN hXxiALAl//LMCNxit9rwbp8PWTxzF9KJhQkv5TOPKDykdabXgDssh2kFsTzV2+xtyJhei60O0goTj psCNF1sOwuUIC0k0l9bWHkBQIn+CCMu0GbGu1SGCedY7KQmnDVYdISo5dhC2wUGj2XJIaKCj9dRNr 1YLcAOlzJL0r+wpvNsTD4tPEF4Dw324lcQUCO71zcHHjCeBlBEUYETxz0EuUCpcw+5py6UWQMYGKr XsC4HKJyw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1g81IY-00009j-Dx; Thu, 04 Oct 2018 10:56:02 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id EE97B202C1A0F; Thu, 4 Oct 2018 12:50:23 +0200 (CEST) Date: Thu, 4 Oct 2018 12:50:23 +0200 From: Peter Zijlstra To: Quentin Perret Cc: rjw@rjwysocki.net, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, gregkh@linuxfoundation.org, mingo@redhat.com, dietmar.eggemann@arm.com, morten.rasmussen@arm.com, chris.redpath@arm.com, patrick.bellasi@arm.com, valentin.schneider@arm.com, vincent.guittot@linaro.org, thara.gopinath@linaro.org, viresh.kumar@linaro.org, tkjos@google.com, joel@joelfernandes.org, smuckle@google.com, adharmap@codeaurora.org, skannan@codeaurora.org, pkondeti@codeaurora.org, juri.lelli@redhat.com, edubezval@gmail.com, srinivas.pandruvada@linux.intel.com, currojerez@riseup.net, javi.merino@kernel.org Subject: Re: [PATCH v7 13/14] sched/topology: Make Energy Aware Scheduling depend on schedutil Message-ID: <20181004105023.GE19252@hirez.programming.kicks-ass.net> References: <20180912091309.7551-1-quentin.perret@arm.com> <20180912091309.7551-14-quentin.perret@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180912091309.7551-14-quentin.perret@arm.com> 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 Wed, Sep 12, 2018 at 10:13:08AM +0100, Quentin Perret wrote: > Energy Aware Scheduling (EAS) is designed with the assumption that > frequencies of CPUs follow their utilization value. When using a CPUFreq > governor other than schedutil, the chances of this assumption being true > are small, if any. When schedutil is being used, EAS' predictions are at > least consistent with the frequency requests. Although those requests > have no guarantees to be honored by the hardware, they should at least > guide DVFS in the right direction and provide some hope in regards to the > EAS model being accurate. > > To make sure EAS is only used in a sane configuration, create a strong > dependency on schedutil being used. Since having sugov compiled-in does > not provide that guarantee, make CPUFreq call a scheduler function on > on governor changes hence letting it rebuild the scheduling domains, > check the governors of the online CPUs, and enable/disable EAS > accordingly. So this patch disables EAS when we change cpufreq gov. How about we force select schedutil and disallow changing it when EAS is enabled? Instead of silently disabling EAS when we frob the governor?