Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp121491ybj; Fri, 8 May 2020 07:54:19 -0700 (PDT) X-Google-Smtp-Source: APiQypJBph4Sa65odsUpSf0s+VyOoZB2l0z6SQ3M3OqbEYFGbnTq5DlHvUj0DR6CzDtP2MDCjkOy X-Received: by 2002:aa7:d78a:: with SMTP id s10mr2489101edq.319.1588949659040; Fri, 08 May 2020 07:54:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588949659; cv=none; d=google.com; s=arc-20160816; b=rDcNPzlWluOIpkNRFCM7gbbrSaBXilWUmPzgFYsDTCXy4xLFAVp/JXO06sBtrGDgYO QwrdbCCgnPRkVxBgnIs5XIQH8so/kpUoNSZfaAO/CsWdTHIMUlNRfwrHlwhMbpHJd+e9 IKdQjA+3AYoO9D6bOSbrwsJFTMHMxkWxHinJyP74WCsJ85EpEjmsnbAejgxkPcmL2JEC zWTE1rnRGq3bVgb9GD+ZmzKFtfNZBvyFoqN36UQH42n7ITD0bbeJuWxrH1g3NVSohq3b Oioj4CCVo3uZGTIvOLfWcQGlJgt97QOc+pzoA/eqgT73qapazeFwaQZeIQSM98J/8OnH 5fhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=H9uy/0kbe+kGBy13gLrl9NVN/7HQ5rXLJhxY6rp+iZk=; b=ifBsdqbqkEiIG8fqHrhQvS/tbnk/Tq/8pKP7y7AdgWWbwnnotlPUMYMBlR1T2fl0he xbtHlxEcTo4P8B6GG2LAaLyQHeapXr7SPYy/O7f9+MYCCqTUMCdz1zEnxxVO3tnN/E2p 56Qdun4DeGF4zTqW8ap6jUDno6BwTn5t4/sGvOd0eBTDqkdWniyU8ueTjXRAl5p41bSV hl1z4VqeNizDpB84v3R6AZDHmcJ+RtJNmeTAhLGc/93bqokQ7MZuOxlQRaQCE91PMSIP MHfwwKND5gyzJRHZuLC4R+4BBX38Eja2h/NbGehJAdvmin23oBSJNh+/Eoe5zDYZPpvX UEhQ== 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 b5si1208685edq.191.2020.05.08.07.53.56; Fri, 08 May 2020 07:54:19 -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 S1727983AbgEHOwQ (ORCPT + 99 others); Fri, 8 May 2020 10:52:16 -0400 Received: from foss.arm.com ([217.140.110.172]:49654 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726751AbgEHOwQ (ORCPT ); Fri, 8 May 2020 10:52:16 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1BF8F1FB; Fri, 8 May 2020 07:52:15 -0700 (PDT) Received: from e113632-lin (e113632-lin.cambridge.arm.com [10.1.194.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 048B93F305; Fri, 8 May 2020 07:52:11 -0700 (PDT) References: <20200507181012.29791-1-qperret@google.com> <20200508131508.GB10541@google.com> User-agent: mu4e 0.9.17; emacs 26.3 From: Valentin Schneider To: Quentin Perret Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, sudeep.holla@arm.com, gregkh@linuxfoundation.org, rafael@kernel.org, viresh.kumar@linaro.org, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, fweisbec@gmail.com, tkjos@google.com, kernel-team@android.com, Ionela Voinescu Subject: Re: [PATCH 00/14] Modularize schedutil In-reply-to: <20200508131508.GB10541@google.com> Date: Fri, 08 May 2020 15:52:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/05/20 14:15, Quentin Perret wrote: > Hey Valentin, > > On Thursday 07 May 2020 at 22:34:17 (+0100), Valentin Schneider wrote: >> I'm curious; why would some Android device not want to roll with schedutil? >> >> When it comes to dynamic policies (i.e. forget performance / powersave, and >> put userspace in a corner), I'd be willing to take a stand and say you >> should only really be using schedutil nowadays - alignment with the >> scheduler, uclamp, yadda yadda. >> >> AFAIA the only schedutil-related quirk we oughta fix for arm/arm64 is that >> arch_scale_freq_invariant() thingie, and FWIW I'm hoping to get something >> regarding this out sometime soonish. After that, I'd actually want to make >> schedutil the default governor for arm/arm64. > > As in setting CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y in the arm64 > defconfig? If so, you have my Acked-by already :) > I'm actually thinking of making it the unconditional default for arm/arm64 in cpufreq's Kconfig, following what has been recently done for intel_pstate. >> I'm not opiniated on the modularization, but if you can, could you please >> share some more details as to why schedutil cannot fulfill its role of holy >> messiah of governors for GKI? > > I guess I answered some of that in the other thread with Peter, but all > in all I'm definitely not trying to make an argument that schedutil > isn't good enough here. I'm trying to say that mandating it in *GKI* is > just likely to cause unnecessary friction, and trust me there is already > enough of that with other topics. Right, I appreciate it must be an "interesting" tug of war. My own opinion has also already been expanded in the rest of the thread; i.e. we should strive to make schedutil good enough that folks don't feel like they still need to use ondemand/whatever frankengov. That said, even without GKI, I get that making some vendors change their already tested-and-tuned setup is an obstacle course in and of itself. > Giving the option of having sugov as a > module doesn't prevent us from making it a default for a few arches, so > I think there is ground for an agreement! > > Cheers, > Quentin