Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2585690imu; Thu, 29 Nov 2018 07:15:04 -0800 (PST) X-Google-Smtp-Source: AFSGD/WT68b+gxW3qIm2exWW/HzsP5gFrpekfV1LDYtIGCtieg7g7CkP02SGWmWQ9jr0KFNCtghN X-Received: by 2002:a17:902:9f93:: with SMTP id g19mr1796477plq.195.1543504504446; Thu, 29 Nov 2018 07:15:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543504504; cv=none; d=google.com; s=arc-20160816; b=d7LulArzcTqle0CuwhuXYq7WL3wpfwBe4zutk3a/5N1JcT/6Cuw52Bc4m0vinvLEok 8E1jvBEONZ6cgEoLRddFQ9MLD8I4I4HEF+H0Zh7pMKcWJBD9ba7W5RD52+NF5iTF9iOo Bqv8F5HG80AWLOmRbqXED9pPcI5tcqh0wGBWf/5zuTgR0iHJCAbAZ8rnRQDU140+CEBV vZt3KokSey6CFJbzIRvnHSS9orRnB4U38bfIR0gMyFptTNdJGKJE4RFMxIz1QzrVa8qd w0u5Rh7RqPMsrrN/jo5a/R99mD5qla01IwWqpKjge7ikMRf1IDUGlyAItIpzqtYZAwPj uFyQ== 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; bh=wktF8Db4Oaii54wbqP9c/2XwpUc5RdDPfsuydtBp7dg=; b=ihgjXfGV4ImRoRnVGQiVVkYwO7sGwPnHyKRE4mVpChMQPBHlbAI0YwueI98zvLiuS2 ossoFfoBHyQlY+xRlGAZ5yhQKTG9v15JD5hPBel1WfpDJeswRF8O7ztVimTwgSDkF+9F DXCYnNRW7Rf2LO2GyzritNNoVStvVO7rPOkPz60MAW7onKGl3gNXNGJLSdHpeQubNAG0 bvNtLn6AkFk5uUqAhyaZ4QnlWq69qxFdV1DQItoB8Jzy9zNArOxMYJW8bX3eg7PH9y3L oXIAmej3WmsARYGqiK7t/z2CWDDYlvx9duJmcuMMEXnzrjG2pjC6qAqjTBoXokACQJLb 1AJA== ARC-Authentication-Results: i=1; mx.google.com; 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 n12si2171437pgb.563.2018.11.29.07.14.40; Thu, 29 Nov 2018 07:15:04 -0800 (PST) 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; 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 S1728590AbeK3CTC (ORCPT + 99 others); Thu, 29 Nov 2018 21:19:02 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:37034 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728128AbeK3CTB (ORCPT ); Thu, 29 Nov 2018 21:19:01 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3A18D80D; Thu, 29 Nov 2018 07:13:21 -0800 (PST) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 03C573F59C; Thu, 29 Nov 2018 07:13:18 -0800 (PST) Date: Thu, 29 Nov 2018 15:13:16 +0000 From: Patrick Bellasi To: Peter Zijlstra Cc: Vincent Guittot , Ingo Molnar , linux-kernel , "Rafael J. Wysocki" , Dietmar Eggemann , Morten Rasmussen , Paul Turner , Ben Segall , Thara Gopinath , pkondeti@codeaurora.org, Quentin Perret , Srinivas Pandruvada Subject: Re: [PATCH v7 2/2] sched/fair: update scale invariance of PELT Message-ID: <20181129151316.GG23094@e110439-lin> References: <1542711308-25256-1-git-send-email-vincent.guittot@linaro.org> <1542711308-25256-3-git-send-email-vincent.guittot@linaro.org> <20181128100241.GA2131@hirez.programming.kicks-ass.net> <20181128115336.GB23094@e110439-lin> <20181129125348.GL2131@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181129125348.GL2131@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29-Nov 13:53, Peter Zijlstra wrote: > On Wed, Nov 28, 2018 at 11:53:36AM +0000, Patrick Bellasi wrote: > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index ac855b2f4774..93e0cf5d8a76 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -3661,6 +3661,10 @@ util_est_dequeue(struct cfs_rq *cfs_rq, struct task_struct *p, bool task_sleep) > > if (!task_sleep) > > return; > > > > + /* Skip samples which do not represent an actual utilization */ > > + if (unlikely(task_util(p) > capacity_of(task_cpu(p)))) > > + return; > > + > > /* > > * If the PELT values haven't changed since enqueue time, > > * skip the util_est update. > > Would you not want something like: > > min(task_util(p), capacity_of(task_cpu(p))) > > And is this the only place where we need this? Mmm... even this could be an over-estimation: I've just posted an example in my last reply to Vincent, end of: Message-ID: <20181129150020.GF23094@e110439-lin> https://lore.kernel.org/lkml/20181129150020.GF23094@e110439-lin/ > OTOH, if the task is always running, it will be always running > irrespective of where it runs. That's not what I'm concerned about. I'm concerned about small tasks which are running on limited capacity (e.g. due to thermal capping) without idle time. In this case, the new "utilization" signal could overestimate the real task needs. > Not storing these samples seems weird though; this is the exact > condition you want to record -- the task is very active, if we skip > these, we'll come back at a low frequency on the next wakeup. When there is not idle time, we don't know if the reported utilization, above the cpu capacity, is due to the task being bigger... or just the new utilization signal converging towards: 100% / RUNNABLE_TASKS_COUNT -- #include Patrick Bellasi