Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7340675imu; Tue, 22 Jan 2019 04:31:38 -0800 (PST) X-Google-Smtp-Source: ALg8bN6sRzaRefitArCpuaySvbWc9Elmks/ZFY9f0io93oWWzZ7CRvhBujL9UpAfwrrmowaG9A1o X-Received: by 2002:a63:fe0a:: with SMTP id p10mr31536006pgh.265.1548160298466; Tue, 22 Jan 2019 04:31:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548160298; cv=none; d=google.com; s=arc-20160816; b=lgE61D3y0UhlcmiFTjRn3ecRzy3B+tdHtJDYb8zUvG9No+NdVKEiVdfTpUKc4JdcbP l3HyledicU8oebcO52YugxLBPDhKIgpM6lWP1/k1oMR6eq0Z1L66RqjmUfvajlXnsrLd 2d6RiJgp2Uitgm0mgSTT80YeDVJ1c9jv21OB01ZCjFsTb3vNWyKnL8JA+JvdKavD8JLo bYoUR02HQJYvib7CTw1Py4Fq90fx1IcGN3N8WPqqcvwOtO5WatYuEO+OvioiyA/CneKK zd1Nad500Uu3U2g+gFv015YYw3JiwUaQsKwxFhqce+iEprLonDNBjD4/3r3i4epIt2bm BflQ== 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=kFnHRUlPXN/xz8XW7Fjkq+dxdlbwDv/wMz/0UddMY8Y=; b=ivQj/4HxeB0MKRR93WhE0GvwkEaZARfWa65Wck03KJ+Ac1vP9NivzQEwvHHUYjtSNH EbXOwCEJ3U0BM+lEPm4DR962Zjsq/xePkOHCkitUV7nHR+cmj3BkxAE2ufd5aWgmK+WU 9OK6y1cyxztpnIVRLKKt4Wod2Tswdfq/cf1pYjjmqB3WZoCd+RPl8R++clXKIwKUOnFy BBTuScnp2HIqSAZ1Wte6HIly0jpSaK+OPYfTxVjelYo4bAoVAXgYEJfl0bWRV2KbIpS7 MBEUK1CQamp5Y8wwKEEGaz8c6c/9Tqcy+5JdHTOkkjQ4ZoWGjR+vuD+ayYh3taSwYT4c ngQQ== 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 g71si5474899pgc.419.2019.01.22.04.31.21; Tue, 22 Jan 2019 04:31:38 -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 S1728344AbfAVMaP (ORCPT + 99 others); Tue, 22 Jan 2019 07:30:15 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:52428 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728209AbfAVMaP (ORCPT ); Tue, 22 Jan 2019 07:30:15 -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 994C9A78; Tue, 22 Jan 2019 04:30:14 -0800 (PST) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A1A253F614; Tue, 22 Jan 2019 04:30:11 -0800 (PST) Date: Tue, 22 Jan 2019 12:30:10 +0000 From: Quentin Perret To: Patrick Bellasi 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: <20190122123007.dkavjh73w223pa6y@queper01-lin> References: <20190115101513.2822-1-patrick.bellasi@arm.com> <20190115101513.2822-10-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190115101513.2822-10-patrick.bellasi@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ? Thanks, Quentin