Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1838615imm; Thu, 27 Sep 2018 03:24:30 -0700 (PDT) X-Google-Smtp-Source: ACcGV60GXwNvFPPlKOpWtm5KtaOmJjy/9d+765b02Ki5hA8E/aeHxcgDjbHDEZCqRcXP9pY8Ybhu X-Received: by 2002:a63:2541:: with SMTP id l62-v6mr293414pgl.343.1538043869902; Thu, 27 Sep 2018 03:24:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538043869; cv=none; d=google.com; s=arc-20160816; b=Cw9mbS8OHQmgmXzPCnWXuZlcVVwgIxHUOCZM9oh1oBlbm1aDofIfuNuCntl3HhxX1q tNgconWaWMcNxkgQbbApyMGDWty0GVGRAmK+fl5+G93RjNt4WE3q2DLk/PGB91jU8e33 OL/MAfx5LZeCPSbcUkpuT1pGB3RVe+iJTseqUdj5Rx/E0ONgscS9qqFuszWwOIaHPOLE SjD4ETufevaPlfD7bTcsnO+TkorrHkKyA86p2+sNP5yeq/HzrYebuYxhz9c3NUt7bhPR 8d+3nztvz78AuJvVG800gGeFqQo3dmR3Uqtim0Xe15/cy53Ar55JU3gPlLNp55rsukO3 WejA== 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=vC6NVdbzePko5zftdPFw+WsGYStBQuJPbWw1qcDvesI=; b=JOSWTohuYNPxNPRk6bNKQW+klVfdHq+kD7egi2kv2AeRbTxXk86vtFOACIWFnA0oG4 bLYRPaJ5bdVZw9JjeUVGDN3PLoQmQMoRxc2Bx3u6mqWK+CMi3wyrUl0sKU7riFeF9rgQ O/6+7HGWzTZH7mY8hxrR/sHvs/BcVdBjECWisosZmEpxm5G6yZSo/prLVJlpeYogURDe +UazMJ4WVZDGVndicU+bmjTPCmQ+A59NkKcgoR26YcxIyh1sOG10n6ti2712rwoasHJT raumOOhTqSjYsICBiGuT5FSdv+mx/nj6UgwIclgkxtS5itiRKGTbY+eZxE1uLTvtepnx W+7Q== 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 27-v6si1588121pgo.671.2018.09.27.03.24.11; Thu, 27 Sep 2018 03:24:29 -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; 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 S1727281AbeI0Qkk (ORCPT + 99 others); Thu, 27 Sep 2018 12:40:40 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:60642 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727230AbeI0Qkj (ORCPT ); Thu, 27 Sep 2018 12:40:39 -0400 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 80CF07A9; Thu, 27 Sep 2018 03:23:05 -0700 (PDT) Received: from queper01-lin (queper01-lin.emea.arm.com [10.4.13.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 77FCD3F5B7; Thu, 27 Sep 2018 03:23:02 -0700 (PDT) Date: Thu, 27 Sep 2018 11:23:00 +0100 From: Quentin Perret To: Patrick Bellasi Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v4 06/16] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Message-ID: <20180927102258.gxhte2k4li2uktm5@queper01-lin> References: <20180828135324.21976-1-patrick.bellasi@arm.com> <20180828135324.21976-7-patrick.bellasi@arm.com> <20180914093240.GB24082@hirez.programming.kicks-ass.net> <20180914131919.GO1413@e110439-lin> <20180914133654.GL24124@hirez.programming.kicks-ass.net> <20180914135712.GQ1413@e110439-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180914135712.GQ1413@e110439-lin> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 14 Sep 2018 at 14:57:12 (+0100), Patrick Bellasi wrote: > On 14-Sep 15:36, Peter Zijlstra wrote: > > On Fri, Sep 14, 2018 at 02:19:19PM +0100, Patrick Bellasi wrote: > > > On 14-Sep 11:32, Peter Zijlstra wrote: > > > > > > Should that not be: > > > > > > > > util = clamp_util(rq, cpu_util_cfs(rq)); > > > > > > > > Because if !util might we not still want to enforce the min clamp? > > > > > > If !util CFS tasks should have been gone since a long time > > > (proportional to their estimated utilization) and thus it probably > > > makes sense to not affect further energy efficiency for tasks of other > > > classes. > > > > I don't remember what we do for util for new tasks; but weren't we > > talking about setting that to 0 recently? IIRC the problem was that if > > we start at 1 with util we'll always run new tasks on big cores, or > > something along those lines. I guess you're referring to that discussion ? https://lore.kernel.org/lkml/CAKfTPtDcoySXK0fBkDNy4wp1vsRxmiuAGT3CDZBh6Vnwyep2BA@mail.gmail.com/ If yes, then the outcome was that we'll see later what we do with new tasks :-) Setting the util of new tasks to 0 surely can help power, but that can also harm performance pretty badly, I think. You'd be stuck at min freq for a while w/ sugov in case of a fork bomb for example. > Mmm.. could have been in a recent discussion with Quentin, but I > think I've missed it. I know we have something similar on Android for > similar reasons. I don't think PELT is different in Android (we still set the initial util of new tasks as half of the spare cap of the CPU), but there are other tweaks that influence the first task placement, though. And WALT sets the util of new tasks to 0 IIRC (but I'm not sure it's relevant since its signal ramps up a lot faster than PELT's). Thanks, Quentin