Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935071AbbGHQsJ (ORCPT ); Wed, 8 Jul 2015 12:48:09 -0400 Received: from mail-pd0-f169.google.com ([209.85.192.169]:36588 "EHLO mail-pd0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933448AbbGHQsF convert rfc822-to-8bit (ORCPT ); Wed, 8 Jul 2015 12:48:05 -0400 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT To: Morten Rasmussen , peterz@infradead.org, mingo@redhat.com From: Michael Turquette In-Reply-To: <1436293469-25707-45-git-send-email-morten.rasmussen@arm.com> Cc: vincent.guittot@linaro.org, daniel.lezcano@linaro.org, "Dietmar Eggemann" , yuyang.du@intel.com, rjw@rjwysocki.net, "Juri Lelli" , sgurrappadi@nvidia.com, pang.xunlei@zte.com.cn, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, "Juri Lelli" References: <1436293469-25707-1-git-send-email-morten.rasmussen@arm.com> <1436293469-25707-45-git-send-email-morten.rasmussen@arm.com> Message-ID: <20150708164744.9112.6023@quantum> User-Agent: alot/0.3.5 Subject: Re: [RFCv5 PATCH 44/46] sched/fair: jump to max OPP when crossing UP threshold Date: Wed, 08 Jul 2015 09:47:44 -0700 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2915 Lines: 71 Quoting Morten Rasmussen (2015-07-07 11:24:27) > From: Juri Lelli > > Since the true utilization of a long running task is not detectable while > it is running and might be bigger than the current cpu capacity, create the > maximum cpu capacity head room by requesting the maximum cpu capacity once > the cpu usage plus the capacity margin exceeds the current capacity. This > is also done to try to harm the performance of a task the least. > > cc: Ingo Molnar > cc: Peter Zijlstra > > Signed-off-by: Juri Lelli > --- > kernel/sched/fair.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 323331f..c2d6de4 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -8586,6 +8586,25 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued) > > if (!rq->rd->overutilized && cpu_overutilized(task_cpu(curr))) > rq->rd->overutilized = true; > + > + /* > + * To make free room for a task that is building up its "real" > + * utilization and to harm its performance the least, request a > + * jump to max OPP as soon as get_cpu_usage() crosses the UP > + * threshold. The UP threshold is built relative to the current > + * capacity (OPP), by using same margin used to tell if a cpu > + * is overutilized (capacity_margin). > + */ > + if (sched_energy_freq()) { > + int cpu = cpu_of(rq); > + unsigned long capacity_orig = capacity_orig_of(cpu); > + unsigned long capacity_curr = capacity_curr_of(cpu); > + > + if (capacity_curr < capacity_orig && > + (capacity_curr * SCHED_LOAD_SCALE) < > + (get_cpu_usage(cpu) * capacity_margin)) > + cpufreq_sched_set_cap(cpu, capacity_orig); I'm sure that at some point the Product People are going to want to tune the capacity value that is requested. Hard-coding the max capacity/frequency in is a reasonable start, but at some point it would be nice to fetch an intermediate capacity defined by the cpufreq driver for this particular cpu. We have already seen that a lot in Android devices using the interactive governor and it could be done from cpufreq_sched_start(). Regards, Mike > + } > } > > /* > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/