Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7348217imu; Tue, 22 Jan 2019 04:39:39 -0800 (PST) X-Google-Smtp-Source: ALg8bN6vzdRSQln8uGOMq7qHKoR2SbZjJb6CMpg0JVGjYdcbbbrvdmOkFv8QtwYLKirvTk3Ryo3A X-Received: by 2002:a63:fc49:: with SMTP id r9mr31219634pgk.209.1548160779116; Tue, 22 Jan 2019 04:39:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548160779; cv=none; d=google.com; s=arc-20160816; b=kVllfc+eRxYYs9nBCPdWG9XItPx6QJDx7v6LoR8WK4sXs4dkw8JBjwJN05WKezLpVg zjYm4g60e5VhJ4i0ZWTinJWEREYv+IfI3cCn/c1DZvttB7OTjVKndwewyU35MP2Svo4j AQ9NDqbxDrznedY7MC1gvBCBzVfS8LaNdyAQSYp3pFOn4aZdwfkTt9xD8S5CLy962dQG kZ8arYRpxAjZUqhoBz9KlG4DKQTkeB+uw6jiLCnnxvkR2rZsOvtGAJLC1jdgQ0SklSDR bWqqIArB7B6hUrdgZ0Pm57SfciA+8/lfGtbxki+UCPs5Q4+nTCakL77CFlwPWP/dFFti imEg== 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=xCFGotoeQDNrxUp91922fe8sBXJmpj3djznyLaezIuQ=; b=Yr7ovg6MU6aedIoCYxI/u74gFO5/WNE9s47ZnPTow0la67qncPrkOwt1DjMosKz2YY YIDjLDKd8bQ30aZAspdR5wy6Gn0pBt/9ESZqC2SqqA4OLUZ5HKoxeR+lweBAlN4wzMQl bumINNUMwMUA0OQHn8n4KJG5GF4rqyFP0wsVpEwlg3aOTwFFeMj3I2aK5nIkWA7jQapz oiF7zXOxDkCMwqO9wuFKtaWyWjZE1Ffs2kb+M2+Oxv8n2dSrBmIWoCD2xSQPZS90h7u0 3kpvtL5Rxxgar2aiSpSCRGrJSszP3ou6Z4wt8y+0ZXA5HX9e3vEkqQzf2zmKu87hxIxb dHOw== 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 e66si1336972plb.107.2019.01.22.04.39.22; Tue, 22 Jan 2019 04:39:39 -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 S1728409AbfAVMhn (ORCPT + 99 others); Tue, 22 Jan 2019 07:37:43 -0500 Received: from foss.arm.com ([217.140.101.70]:52522 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728339AbfAVMhn (ORCPT ); Tue, 22 Jan 2019 07:37:43 -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 550F2EBD; Tue, 22 Jan 2019 04:37:42 -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 60F1D3F614; Tue, 22 Jan 2019 04:37:39 -0800 (PST) Date: Tue, 22 Jan 2019 12:37:04 +0000 From: Patrick Bellasi To: Quentin Perret Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan Subject: Re: [PATCH v6 09/16] sched/cpufreq: uclamp: Add utilization clamping for RT tasks Message-ID: <20190122123704.6rb3xemvxbp5yfjq@e110439-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-10-patrick.bellasi@arm.com> <20190122123007.dkavjh73w223pa6y@queper01-lin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190122123007.dkavjh73w223pa6y@queper01-lin> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22-Jan 12:30, Quentin Perret wrote: > On Tuesday 15 Jan 2019 at 10:15:06 (+0000), Patrick Bellasi wrote: > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c > > index 520ee2b785e7..38a05a4f78cc 100644 > > --- a/kernel/sched/cpufreq_schedutil.c > > +++ b/kernel/sched/cpufreq_schedutil.c > > @@ -201,9 +201,6 @@ unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs, > > unsigned long dl_util, util, irq; > > struct rq *rq = cpu_rq(cpu); > > > > - if (type == FREQUENCY_UTIL && rt_rq_is_runnable(&rq->rt)) > > - return max; > > - > > /* > > * Early check to see if IRQ/steal time saturates the CPU, can be > > * because of inaccuracies in how we track these -- see > > @@ -219,15 +216,19 @@ unsigned long schedutil_freq_util(int cpu, unsigned long util_cfs, > > * utilization (PELT windows are synchronized) we can directly add them > > * to obtain the CPU's actual utilization. > > * > > - * CFS utilization can be boosted or capped, depending on utilization > > - * clamp constraints requested by currently RUNNABLE tasks. > > + * CFS and RT utilization can be boosted or capped, depending on > > + * utilization clamp constraints requested by currently RUNNABLE > > + * tasks. > > * When there are no CFS RUNNABLE tasks, clamps are released and > > * frequency will be gracefully reduced with the utilization decay. > > */ > > - util = (type == ENERGY_UTIL) > > - ? util_cfs > > - : uclamp_util(rq, util_cfs); > > - util += cpu_util_rt(rq); > > + util = cpu_util_rt(rq); > > + if (type == FREQUENCY_UTIL) { > > + util += cpu_util_cfs(rq); > > + util = uclamp_util(rq, util); > > So with this we don't go to max to anymore for CONFIG_UCLAMP_TASK=n no ? Mmm... good point! I need to guard this chagen for the !CONFIG_UCLAMP_TASK case! > > Thanks, > Quentin Cheers Patrick -- #include Patrick Bellasi