Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp82086imm; Tue, 5 Jun 2018 15:29:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLyEX/1NSJ0HbBKLGZWjrbfFpAJdtqCvh4mm0JHONVS/JDK3jPGAqYCuBlpH8xroiIiMKcG X-Received: by 2002:a63:6f42:: with SMTP id k63-v6mr365979pgc.135.1528237774547; Tue, 05 Jun 2018 15:29:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528237774; cv=none; d=google.com; s=arc-20160816; b=F9jVGuptTjnb0fXOiLMBmu2jR5j0orFLlu2VWW2KnAG6T9IH5zvhyZIAewaC0J8ey4 7Z842DLazaW6fNxfcC6FKHYp2R+fhP0hYYFkeMeop3Jo+4tHsJklX12tDrZKJu3j5EnW sYY0kigjHzAchfAGLRjolh+v6J3yaCfyg+6SJAzcQIcXhKWPQ6Lkxj2E4y8iL0f01nX4 L/7IFs4GejZOI+VRCXbb+ZlLmFNkNCpZZ+uzgT5bWxVZK4+sW48udAyAb/kD9k+WK+8X Um4IzfdWFR8CWjXfjFAhYhk7Q/gxwnUhXKmgB6jsnmIsTpQe9GK9xEkYuiqb8ImvzGEC O/4w== 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:arc-authentication-results; bh=XU0h4Pe7sYuCCB+k7hXrwcRpQyFID/UD8DgGdH79g8g=; b=FhPDsq1xi1OHwbyDrO09SXHSnn4i8SSpDWmK+azmOw/OUj78rbhueS7SvUGWaZJ18t UiEth5ad0PjyIWgmM9kM2k6LFKlLcTCWzBakEDrA5KQ2yIkrqFANuYVUe+rZEKsilnVU 2BTJpBiQboEBm+xKyYCCw9+lw3D2DXQVKBebbAYboPPu38ZmyGrrMKnizF3LBkzssCzw 0qYLSA6q1flGzDwhlV9bqN8RHsArRkGOLeCIenZFvi4t/jNRRczhOszNw7fsMkA07xbv UtmS0w15wUTFX7t9ooR3a/oOZ+PPRxproFuUBLbu4A1Dg7iiz6g1gthJ8CThRTcOCmjI wRDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=jWK+TCnO; 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 k2-v6si5672553pgr.206.2018.06.05.15.29.20; Tue, 05 Jun 2018 15:29:34 -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=bombadil.20170209 header.b=jWK+TCnO; 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 S932090AbeFEW1k (ORCPT + 99 others); Tue, 5 Jun 2018 18:27:40 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:45354 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932070AbeFEW1j (ORCPT ); Tue, 5 Jun 2018 18:27:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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=XU0h4Pe7sYuCCB+k7hXrwcRpQyFID/UD8DgGdH79g8g=; b=jWK+TCnOIIsJUuKvgNIKWw9zg 6k41uorNNS0JBJpTrsB/6+50+ZtK3r/BQ4hKQNEIHlNHXI2Gn8xgd0DJg+OV4oD1Scu09OQs7Irob oy8ERYTnSVtPLnXnyEBHmPJ1SkPMKi9lFGclyCbyQ6f1/UpCQ1mzq5b+Wg3CqdHZrbE+g50P58b6J RHsnwrr5pmBoVXReyJbc4A2IpTfzgDe9lC1B21zOf0DE65mPINah9h98lFXmw/w+M5IBBvXCbm5SG 0YSTv3Wr7roni120aQA+ClvPxX3TfQVBPcoRv25zZ2rRpBaF3oHGpWIZhmxVYPbcneQG0co9kGMTg avvpk/ZfQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fQKQO-0001vG-GZ; Tue, 05 Jun 2018 22:27:32 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id BBBED201EA7AC; Wed, 6 Jun 2018 00:27:30 +0200 (CEST) Date: Wed, 6 Jun 2018 00:27:30 +0200 From: Peter Zijlstra To: Patrick Bellasi Cc: Vincent Guittot , Ingo Molnar , linux-kernel , "Rafael J. Wysocki" , Juri Lelli , Dietmar Eggemann , Morten Rasmussen , viresh kumar , Valentin Schneider , Quentin Perret Subject: Re: [PATCH v5 00/10] track CPU utilization Message-ID: <20180605222730.GA12180@hirez.programming.kicks-ass.net> References: <1527253951-22709-1-git-send-email-vincent.guittot@linaro.org> <20180604165047.GU12180@hirez.programming.kicks-ass.net> <20180605141809.GV12180@hirez.programming.kicks-ass.net> <20180605153826.GE32302@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180605153826.GE32302@e110439-lin> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 05, 2018 at 04:38:26PM +0100, Patrick Bellasi wrote: > On 05-Jun 16:18, Peter Zijlstra wrote: > > On Mon, Jun 04, 2018 at 08:08:58PM +0200, Vincent Guittot wrote: > > > As you mentioned, scale_rt_capacity give the remaining capacity for > > > cfs and it will behave like cfs util_avg now that it uses PELT. So as > > > long as cfs util_avg < scale_rt_capacity(we probably need a margin) > > > we keep using dl bandwidth + cfs util_avg + rt util_avg for selecting > > > OPP because we have remaining spare capacity but if cfs util_avg == > > > scale_rt_capacity, we make sure to use max OPP. > > What will happen for the 50% task of the example above? When the cfs-cap reaches 50% (where cfs_cap := 1 - rt_avg - dl_avg - stop_avg - irq_avg) a cfs-util of 50% means that there is no idle time. So util will still be 50%, nothing funny. But frequency selection will see util==cap and select max (it might not have because reduction could be due to IRQ pressure for example). At the moment cfs-cap rises (>50%), and the cfs-util stays at 50%, we'll have 50% utilization. We know there is idle time, the task could use more if it wanted to. > > Good point, when cfs-util < cfs-cap then there is idle time and the util > > number is 'right', when cfs-util == cfs-cap we're overcommitted and > > should go max. > > Again I cannot easily read the example above... > > Would that mean that a 50% CFS task, preempted by a 50% RT task (which > already set OPP to max while RUNNABLE) will end up running at the max > OPP too? Yes, because there is no idle time. When there is no idle time, max freq is the right frequency. The moment cfs-util drops below cfs-cap, we'll stop running at max, because at that point we've found idle time to reduce frequency with. > > Since the util and cap values are aligned that should track nicely. > > True... the only potential issue I see is that we are steering PELT > behaviors towards better driving schedutil to run high-demand > workloads while _maybe_ affecting quite sensibly the capacity of PELT > to describe how much CPU a task uses. > > Ultimately, utilization has always been a metric on "how much you > use"... while here it seems to me we are bending it to be something to > define "how fast you have to run". This latest proposal does not in fact change the util tracking. But in general, 'how much do you use' can be a very difficult question, see the whole turbo / hardware managed dvfs discussion a week or so ago.