Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2455590imm; Mon, 28 May 2018 08:23:45 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJlQQHyQJyaoTbcbNHwNtJ1sFVGbDRqS/8OLXT+0sfw72QX17i49Yx1Rtam6z128VIIWtDD X-Received: by 2002:a17:902:7d02:: with SMTP id z2-v6mr5561834pll.104.1527521025298; Mon, 28 May 2018 08:23:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527521025; cv=none; d=google.com; s=arc-20160816; b=UpRV5v6EPY2djWPQrIIN4uiV7f1gDyt0fvc7AOEjBNtlAudFrG8RGw0Qf8o8KPP4dp S3sZ2txCkfUkMvuIPN66Sa8VB3oiYKZlYgpLlenLVFL4VgQWJjr4b1hmlLyKILJvyntt Q9r70KkXzGv2dAIl2izqM3t/8d64FAy2yyI5jdHUNmuWyoAWY/CLCHQDviuz1oPBiEi8 bt5pE94B9Vy8XIq+ELocwWgaCSCTyKfe/XY1psGZvmWu0/vrLok976qFUC5qcdUEngmb 67EHAr/g44QCQ9BO2AeSZ+4tVMzLKSwOgRmFATY9HC+ggModkm8VMBBDxjle78h449GY 3bgA== 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=stX+YN9IcUmoJB4/M9j2aD6B2RKJiLyVbIe0ER8wHSI=; b=s6WXzuGns6VbAMMR7Cmfvoh+ru/QqkgDc99asuKsam1WcA0LDCUD9FbYOrUp6aQL9t gSRar9BgSiExuWC8+x0uFWfpzFOhn48efqb5LYFWByB7nakFOgfQh4muMe22PkwpjJTv DucY3fB5Z/UUrR30xKq+2UAG3bSwlf97NkYg/g86L8RPhynYgJPJluoi9C98sIjYcXbf +wFNtjok20V48rhaKLW2MHqfFMia3nYkZD+OQanOHOAYH2quLyoAW+Qy4EDrA8XY/ClL st+4ToKbyTeLW/5Nbqb8Ax67JrdTG3RcOIZrk31BJL6DFe/STCRW9DwxPmFB3EfUW/O9 G61g== 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 b5-v6si8701491plx.4.2018.05.28.08.23.30; Mon, 28 May 2018 08:23:45 -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 S969061AbeE1PWx (ORCPT + 99 others); Mon, 28 May 2018 11:22:53 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:44961 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1033328AbeE1PWr (ORCPT ); Mon, 28 May 2018 11:22:47 -0400 Received: by mail-wr0-f196.google.com with SMTP id y15-v6so20853631wrg.11 for ; Mon, 28 May 2018 08:22:47 -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=stX+YN9IcUmoJB4/M9j2aD6B2RKJiLyVbIe0ER8wHSI=; b=alp82Dol0ZTd+zzSBm+EiekzWpK/8ZDbhX4QCIk+FlnPiroQf5wXpCPqQUvnmp43u0 J8HygCa9lxg9G03V1bMBFoUfH2biYTQGA3TlZbil+rgzCcyyyLLoJIXwT7TQNFOTDfIN kPI1E1swWa+vvdzLutj3NsLPNjvuZFNo0NM2gorrFJ7EYuzc2ehcYlVvbkxDpYrXtbp1 PzcqCM09q84lI6VU+IkdZYq/f5HtcgnVl88HmVPPkfXni4vo33cZ05Pcdwcif/RvfNx2 6FMGmLyhsAZ0MdKIT9XMSPHWefblgCzr0qYxwjsBmooEx5MPxDAxD5Pgq19+V2JIsGWG 2WIg== X-Gm-Message-State: ALKqPwdaVSnnxqvh8Gdkop+9jile9wNb1QyNQAdobuiX5Ae24O5xei1b ubBKqvxE8Pg6y3kYyDhT+eXq2A== X-Received: by 2002:adf:8854:: with SMTP id e20-v6mr11980094wre.30.1527520966572; Mon, 28 May 2018 08:22:46 -0700 (PDT) Received: from localhost.localdomain ([151.15.207.242]) by smtp.gmail.com with ESMTPSA id n17-v6sm27132485wra.3.2018.05.28.08.22.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 28 May 2018 08:22:45 -0700 (PDT) Date: Mon, 28 May 2018 17:22:43 +0200 From: Juri Lelli To: Vincent Guittot Cc: Peter Zijlstra , Ingo Molnar , linux-kernel , "Rafael J. Wysocki" , Dietmar Eggemann , Morten Rasmussen , viresh kumar , Valentin Schneider , Quentin Perret , Luca Abeni , Claudio Scordino , Joel Fernandes , Alessio Balsini Subject: Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization Message-ID: <20180528152243.GD1293@localhost.localdomain> References: <1527253951-22709-1-git-send-email-vincent.guittot@linaro.org> <1527253951-22709-6-git-send-email-vincent.guittot@linaro.org> <20180528101234.GA1293@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 28/05/18 16:57, Vincent Guittot wrote: > Hi Juri, > > On 28 May 2018 at 12:12, Juri Lelli wrote: > > Hi Vincent, > > > > On 25/05/18 15:12, Vincent Guittot wrote: > >> Now that we have both the dl class bandwidth requirement and the dl class > >> utilization, we can use the max of the 2 values when agregating the > >> utilization of the CPU. > >> > >> Signed-off-by: Vincent Guittot > >> --- > >> kernel/sched/sched.h | 6 +++++- > >> 1 file changed, 5 insertions(+), 1 deletion(-) > >> > >> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > >> index 4526ba6..0eb07a8 100644 > >> --- a/kernel/sched/sched.h > >> +++ b/kernel/sched/sched.h > >> @@ -2194,7 +2194,11 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {} > >> #ifdef CONFIG_CPU_FREQ_GOV_SCHEDUTIL > >> static inline unsigned long cpu_util_dl(struct rq *rq) > >> { > >> - return (rq->dl.running_bw * SCHED_CAPACITY_SCALE) >> BW_SHIFT; > >> + unsigned long util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE) >> BW_SHIFT; > > > > I'd be tempted to say the we actually want to cap to this one above > > instead of using the max (as you are proposing below) or the > > (theoretical) power reduction benefits of using DEADLINE for certain > > tasks might vanish. > > The problem that I'm facing is that the sched_entity bandwidth is > removed after the 0-lag time and the rq->dl.running_bw goes back to > zero but if the DL task has preempted a CFS task, the utilization of > the CFS task will be lower than reality and schedutil will set a lower > OPP whereas the CPU is always running. The example with a RT task > described in the cover letter can be run with a DL task and will give > similar results. > avg_dl.util_avg tracks the utilization of the rq seen by the scheduler > whereas rq->dl.running_bw gives the minimum to match DL requirement. Mmm, I see. Note that I'm only being cautious, what you propose might work OK, but it seems to me that we might lose some of the benefits of running tasks with DEADLINE if we start selecting frequency as you propose even when such tasks are running. An idea might be to copy running_bw util into dl.util_avg when a DL task goes to sleep, and then decay the latter as for RT contribution. What you think?