Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp369383imm; Thu, 31 May 2018 01:48:17 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLMfJiR5NWD2HxEQPzpQ7h4d8WpEIsMS3nn4xwr0mhwjYobduEpiAIfsnXr8ZGLdXlIJRQK X-Received: by 2002:a17:902:9a4b:: with SMTP id x11-v6mr6224567plv.176.1527756496999; Thu, 31 May 2018 01:48:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527756496; cv=none; d=google.com; s=arc-20160816; b=OQG3xOYwyR2xL5dKIdAqpz3oUfgO8dJfdtIKC41T+6fCjeaKB3IMT1Uk2ZSQil0a4v HlOH56w1mcOQg+jXvbS0AzTqU+cQo4qiAkQSSGaJnSFNNGEt4rKumw7NR9FpUUUvLAM3 igYF94PIisc/G+U7Mjoq6YY7oT4NL5FJwkRJt6yEa2HrqZuEzTYdD7zBO7/0yCK+JbFn eABJJC4ujvNFLXw/JiVFroxWs+L6zQanKFcRGv8nJ1scqBeNYf8Ol2ZeyBIp0EmkmP5R IiDrUbQxrs9m6nJXEAlH8NJxYHRV+CiDxk+6DYWblUYHvkvkqDKy/MsRZ5Fqf7ZJGSGu viHg== 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:arc-authentication-results; bh=BNAeSxkYlHGtNoOsY0bu/OkEQSwUFxiMV57c3FaSjd4=; b=WD0yMp0zCmo5g+VUXmETk6XZ6n5blgjcfyhxK8SpG+SGqpyVvfj7FZ/8Uem9RjNdiG +nN1XsPMD0LXqLxenDQkBbKVCis7b+AeNkypPq7fswyXWpbdIfletbeDY+MJY88Cc6p1 EHWFxVSca4CR0YyyoZOHx1qwvvqoGE30uBXHZPLO+PdK7mrG8VtXuPzIkubONcY14NHp kgec4c+6lQFYYpal2+fuSVdEmSP1RwlKJPJpl393oMznygeGXsU6RMF6x8ySc4SGY8e3 QAUq5cqnbH1dCU/BdgtrBHK/QsaCw8i7zR/T1TitB8yVXfqXOGSxFtUNVXRBdR0vx0bt Ut2g== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x1-v6si35160264pfm.32.2018.05.31.01.48.02; Thu, 31 May 2018 01:48:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754112AbeEaIqQ (ORCPT + 99 others); Thu, 31 May 2018 04:46:16 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:54495 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754040AbeEaIqM (ORCPT ); Thu, 31 May 2018 04:46:12 -0400 Received: by mail-wm0-f67.google.com with SMTP id f6-v6so52503657wmc.4 for ; Thu, 31 May 2018 01:46:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BNAeSxkYlHGtNoOsY0bu/OkEQSwUFxiMV57c3FaSjd4=; b=EhN2wF0h7bgzSYTpiPNkt2PqYHXHWp5gEcNb42s7suOdOUwhXKfGACrDRBwwUDNUxv BtwTQVOyByzWj//GX2VM0pxd3Hntjf/RAGqrINIyygNZ5wNXyhU32slY0xF4HMufbeXh eCH5nzseMRDv5MkV/iPWf/JEE2VBw8kzIElzbVaZ5ARQOq2igF/ckXpY3mKlmG6DJaPz +dIGDGikfvZc5Q3hwNQLgw8rAJk356V4EiQMCzsx4skil2FlhS+4d3tFCbcWBPNZRHMV 27bFISkQiuMFmYOE+aDN6wSbGpIdcDAU/sUW+cpDmcquccmy1j/ErFm9p3nmKw3gDOO9 D1fg== X-Gm-Message-State: ALKqPwfKlSRLGugdKcA+e5ikg42Jv3LoBqIWOaxLTaZFlPKXyjS+dwRR DJogpIdKWc1CSdITGk9QaDJyag== X-Received: by 2002:a1c:8b88:: with SMTP id n130-v6mr3559803wmd.8.1527756370842; Thu, 31 May 2018 01:46:10 -0700 (PDT) Received: from localhost.localdomain ([151.15.207.242]) by smtp.gmail.com with ESMTPSA id t11-v6sm8037978wrp.94.2018.05.31.01.46.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 May 2018 01:46:10 -0700 (PDT) Date: Thu, 31 May 2018 10:46:07 +0200 From: Juri Lelli To: Quentin Perret Cc: Vincent Guittot , peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, rjw@rjwysocki.net, dietmar.eggemann@arm.com, Morten.Rasmussen@arm.com, viresh.kumar@linaro.org, valentin.schneider@arm.com Subject: Re: [PATCH v5 03/10] cpufreq/schedutil: add rt utilization tracking Message-ID: <20180531084607.GB17937@localhost.localdomain> References: <1527253951-22709-1-git-send-email-vincent.guittot@linaro.org> <1527253951-22709-4-git-send-email-vincent.guittot@linaro.org> <20180530164601.GC2174@e108498-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180530164601.GC2174@e108498-lin.cambridge.arm.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/05/18 17:46, Quentin Perret wrote: > Hi Vincent, > > On Friday 25 May 2018 at 15:12:24 (+0200), Vincent Guittot wrote: > > Add both cfs and rt utilization when selecting an OPP for cfs tasks as rt > > can preempt and steal cfs's running time. > > > > Signed-off-by: Vincent Guittot > > --- > > kernel/sched/cpufreq_schedutil.c | 14 +++++++++++--- > > 1 file changed, 11 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > > index 28592b6..a84b5a5 100644 > > --- a/kernel/sched/cpufreq_schedutil.c > > +++ b/kernel/sched/cpufreq_schedutil.c > > @@ -56,6 +56,7 @@ struct sugov_cpu { > > /* The fields below are only needed when sharing a policy: */ > > unsigned long util_cfs; > > unsigned long util_dl; > > + unsigned long util_rt; > > unsigned long max; > > > > /* The field below is for single-CPU policies only: */ > > @@ -178,14 +179,21 @@ static void sugov_get_util(struct sugov_cpu *sg_cpu) > > sg_cpu->max = arch_scale_cpu_capacity(NULL, sg_cpu->cpu); > > sg_cpu->util_cfs = cpu_util_cfs(rq); > > sg_cpu->util_dl = cpu_util_dl(rq); > > + sg_cpu->util_rt = cpu_util_rt(rq); > > } > > > > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu) > > { > > struct rq *rq = cpu_rq(sg_cpu->cpu); > > + unsigned long util; > > > > - if (rq->rt.rt_nr_running) > > - return sg_cpu->max; > > + if (rq->rt.rt_nr_running) { > > + util = sg_cpu->max; > > So I understand why we want to got to max freq when a RT task is running, > but I think there are use cases where we might want to be more conservative > and use the util_avg of the RT rq instead. The first use case is > battery-powered devices where going to max isn't really affordable from > an energy standpoint. Android, for example, has been using a RT > utilization signal to select OPPs for quite a while now, because going > to max blindly is _very_ expensive. > > And the second use-case is thermal pressure. On some modern CPUs, going to > max freq can lead to stringent thermal capping very quickly, at the > point where your CPUs might not have enough capacity to serve your tasks > properly. And that can ultimately hurt the very RT tasks you originally > tried to run fast. In these systems, in the long term, you'd be better off > not asking for more than what you really need ... Proposed the same at last LPC. Peter NAKed it (since RT is all about meeting deadlines, and when using FIFO/RR we don't really know how fast the CPU should go to meet them, so go to max is the only safe decision). > So what about having a sched_feature to select between going to max and > using the RT util_avg ? Obviously the default should keep the current > behaviour. Peter, would SCHED_FEAT make a difference? :) Or Patrick's utilization capping applied to RT..