[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2cbde0fe-c10c-0ebb-32ef-2d522986bc89@arm.com>
Date: Fri, 18 Oct 2019 09:44:44 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Peter Zijlstra <peterz@...radead.org>,
Quentin Perret <qperret@...gle.com>
Cc: Douglas Raillard <douglas.raillard@....com>,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
mingo@...hat.com, rjw@...ysocki.net, viresh.kumar@...aro.org,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
qperret@...rret.net, patrick.bellasi@...bug.net, dh.han@...sung.com
Subject: Re: [RFC PATCH v3 0/6] sched/cpufreq: Make schedutil energy aware
On 17/10/2019 16:11, Peter Zijlstra wrote:
> On Thu, Oct 17, 2019 at 12:11:16PM +0100, Quentin Perret wrote:
[...]
> It only boosts when 'rq->cfs.avg.util' increases while
> 'rq->cfs.avg.util_est.enqueued' remains unchanged (and util > util_est
> obv).
>
> This condition can be true for select_task_rq_fair(), because that is
> ran before we do enqueue_task_fair() (for obvious raisins).
>
>>> I'm still thinking about the exact means you're using to raise C; that
>>> is, the 'util - util_est' as cost_margin. It hurts my brain still.
>>
>> +1 ...
>
> cost_i = capacity_i / power_i ; for the i-th OPP
I get confused by this definition. efficiency=capacity/power but the
cs->cost value used in em_pd_get_higher_freq() is defined as
cs_cost = cs->power * cpu_max_freq / cs->freq [energy_model.h]
> We then do: 'x = util - util_avg' and use that on the first
> OPP >= min_freq:
>
> cost(x) = cost_j + cost_j * x ; freq_j >= min_freq
> = cost_j * (1 + x)
>
> And then we find the highest OPP that has:
>
> cost_k <= cost(x)
[...]
Powered by blists - more mailing lists