All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukasz Luba <lukasz.luba@arm.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Quentin Perret <qperret@google.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	vincent.donnefort@arm.com, Beata.Michalska@arm.com,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	segall@google.com, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH v2 2/2] sched/cpufreq: Consider reduced CPU capacity in energy calculation
Date: Thu, 10 Jun 2021 09:19:08 +0100	[thread overview]
Message-ID: <6b10f1ed-17d7-e1b0-37c5-17ced9ba383c@arm.com> (raw)
In-Reply-To: <CAJZ5v0ji=601eHQzHP1KuiA_TRUBaeEL6=sSLR_sW12MS_8QcA@mail.gmail.com>



On 6/9/21 4:01 PM, Rafael J. Wysocki wrote:
> On Fri, Jun 4, 2021 at 10:10 AM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> Energy Aware Scheduling (EAS) needs to predict the decisions made by
>> SchedUtil. The map_util_freq() exists to do that.
>>
>> There are corner cases where the max allowed frequency might be reduced
>> (due to thermal). SchedUtil as a CPUFreq governor, is aware of that
>> but EAS is not. This patch aims to address it.
>>
>> SchedUtil stores the maximum allowed frequency in
>> 'sugov_policy::next_freq' field. EAS has to predict that value, which is
>> the real used frequency. That value is made after a call to
>> cpufreq_driver_resolve_freq() which clamps to the CPUFreq policy limits.
>> In the existing code EAS is not able to predict that real frequency.
>> This leads to energy estimation errors.
>>
>> To avoid wrong energy estimation in EAS (due to frequency miss prediction)
>> make sure that the step which calculates Performance Domain frequency,
>> is also aware of the allowed CPU capacity.
>>
>> Furthermore, modify map_util_freq() to not extend the frequency value.
>> Instead, use map_util_perf() to extend the util value in both places:
>> SchedUtil and EAS, but for EAS clamp it to max allowed CPU capacity.
>> In the end, we achieve the same desirable behavior for both subsystems
>> and alignment in regards to the real CPU frequency.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
> 
> For the schedutil part
> 
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 


Thank you Rafael!

Regards,
Lukasz

      reply	other threads:[~2021-06-10  8:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04  8:09 [PATCH v2 0/2] Add allowed CPU capacity knowledge to EAS Lukasz Luba
2021-06-04  8:09 ` [PATCH v2 1/2] sched/fair: Take thermal pressure into account while estimating energy Lukasz Luba
2021-06-10  7:59   ` Vincent Guittot
2021-06-10  8:42     ` Lukasz Luba
2021-06-10  9:11       ` Vincent Guittot
2021-06-10  9:36         ` Lukasz Luba
2021-06-10  9:41           ` Vincent Guittot
2021-06-10  9:52             ` Lukasz Luba
2021-06-10  9:45           ` Vincent Guittot
2021-06-10  8:42   ` Dietmar Eggemann
2021-06-10  9:04     ` Lukasz Luba
2021-06-10 10:07       ` Dietmar Eggemann
2021-06-10 10:37         ` Lukasz Luba
2021-06-10 12:19           ` Vincent Guittot
2021-06-10 12:30             ` Lukasz Luba
2021-06-10 12:40               ` Vincent Guittot
2021-06-10 12:53                 ` Lukasz Luba
2021-06-04  8:09 ` [PATCH v2 2/2] sched/cpufreq: Consider reduced CPU capacity in energy calculation Lukasz Luba
2021-06-09 15:01   ` Rafael J. Wysocki
2021-06-10  8:19     ` Lukasz Luba [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6b10f1ed-17d7-e1b0-37c5-17ced9ba383c@arm.com \
    --to=lukasz.luba@arm.com \
    --cc=Beata.Michalska@arm.com \
    --cc=bristot@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=segall@google.com \
    --cc=vincent.donnefort@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.