Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1313881pxb; Fri, 20 Nov 2020 06:41:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJzGbnqDnySzXUhItHRrTr5jcmYXnuaO/no6UNFMWjHfpRAlJ3BI9KGewlCKBM0qRPKsoTbD X-Received: by 2002:a17:906:3ec8:: with SMTP id d8mr33735330ejj.32.1605883314111; Fri, 20 Nov 2020 06:41:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605883314; cv=none; d=google.com; s=arc-20160816; b=ljPFxqQ2kLcP6fQ5iXE/0H7p5o3dS4PWAVtbydYPsnjyKpE8Q4RqhaUtRGUk4frwob 5fBXVyAnYrtv+0s/3KtXDleJY2Cw6k0xCxiUqiHGR4gww+V+P6lGnNSjb4wBph2ksW+f NCDy4E4inJTlp0syPuRADJMp/0NuJU6FhSUazVnluL7DGPZ6ESf5Ss67C284yTUh32rS sF1650+C3sJ6nUvjgsUer4DweCU8ee+/v4XAeeHxa4z0clcxunOnCqbVhk32m2t4RJm/ CT5UjMK8mMPWCjAp6wC5NGHKliwVbxAo6nsRuCF/N0h6j1QAv05dr+PMuZX8rRD5FsF4 F6CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=TkcuOzXuM4SyoukbSfzvfORgscQgb9/pCf1Mf5l5wH8=; b=bksmU7xBrB9c51Ulnm/y4v6C2o2TGdKcQkNT2Fn/8G58wSXDlaQkYaakQYAllgXIA2 DiJRCFJBKsdG6WY8Je5SPe7o27o0rGfI/+aX/wrr8e8OJX0vdIYdAk46qYVyP/V+UdrD FFb//+M01awVcDpBjsA9BT7MeXNbxFqFF+oUUvqM9lZREwJbwVGh3v0LjAUDTUME8WZG 30BfIUvwyK9BNkG+LtlLKls/unxjTQtVnUVp4T4RSJCuY0jegeaxwn+mFbM8IskYgeFB IEb631n4S7ARTtYNoSyCQzkfsOHsoRMqoly3CfjvF0CxU0JL2OGc6Qeu9mv58apXbEz8 ttOA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v5si2406962edi.183.2020.11.20.06.41.30; Fri, 20 Nov 2020 06:41:54 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728017AbgKTOiG (ORCPT + 99 others); Fri, 20 Nov 2020 09:38:06 -0500 Received: from foss.arm.com ([217.140.110.172]:50090 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727241AbgKTOiG (ORCPT ); Fri, 20 Nov 2020 09:38:06 -0500 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 6025311D4; Fri, 20 Nov 2020 06:38:05 -0800 (PST) Received: from e123083-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 80AD73F718; Fri, 20 Nov 2020 06:38:03 -0800 (PST) Date: Fri, 20 Nov 2020 15:37:55 +0100 From: Morten Rasmussen To: Peter Zijlstra Cc: "Rafael J. Wysocki" , Ingo Molnar , Thomas Gleixner , Vincent Guittot , dietmar.eggemann@arm.com, patrick.bellasi@matbug.net, lenb@kernel.org, linux-kernel@vger.kernel.org, valentin.schneider@arm.com, ionela.voinescu@arm.com, qperret@google.com, viresh.kumar@linaro.org Subject: Re: [RFC] Documentation/scheduler/schedutil.txt Message-ID: <20201120143715.GA3456@e123083-lin> References: <20201120075527.GB2414@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201120075527.GB2414@hirez.programming.kicks-ass.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter, Looks like a nice summary to me. On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote: > Hi, > > I was recently asked to explain how schedutil works, the below write-up > is the result of that and I figured we might as well stick it in the > tree. > > Not as a patch for easy reading and commenting. > > --- > > NOTE; all this assumes a linear relation between frequency and work capacity, > we know this is flawed, but it is the best workable approximation. If you replace frequency with performance level everywhere (CPPC style), most of it should still work without that assumption. The assumption might have be made in hw or fw instead though. Morten