mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thara Gopinath <thara.gopinath@linaro.org>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Quentin Perret <qperret@google.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: mingo@redhat.com, ionela.voinescu@arm.com,
	vincent.guittot@linaro.org, rui.zhang@intel.com,
	daniel.lezcano@linaro.org, viresh.kumar@linaro.org,
	linux-kernel@vger.kernel.org, amit.kachhap@gmail.com,
	javi.merino@kernel.org, amit.kucheria@verdurent.com
Subject: Re: [Patch v6 4/7] sched/fair: Enable periodic update of average thermal pressure
Date: Fri, 27 Dec 2019 10:22:13 -0500	[thread overview]
Message-ID: <5E0621A5.5040901@linaro.org> (raw)
In-Reply-To: <78b0f8a6-462b-acca-7682-f5269fea17c5@arm.com>

On 12/17/2019 07:57 AM, Dietmar Eggemann wrote:
> On 16/12/2019 18:59, Quentin Perret wrote:
>> On Monday 16 Dec 2019 at 15:39:32 (+0100), Peter Zijlstra wrote:
>>>> @@ -10274,6 +10281,7 @@ static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
>>>>  
>>>>  	update_misfit_status(curr, rq);
>>>>  	update_overutilized_status(task_rq(curr));
>>>> +	update_thermal_load_avg(rq_clock_task(rq), rq, thermal_pressure);
>>>>  }
>>>
>>> My objection here is that when the arch does not have support for it,
>>> there is still code generated and runtime overhead associated with it.
>>
>> I guess this function could be stubbed for CONFIG_CPU_THERMAL=n ?
>> That is, reflecting the thermal pressure in the scheduler only makes
>> sense when the thermal infrastructure is enabled to begin with (which is
>> indeed not the case for most archs).
> 
> Makes sense to me. If we can agree that 'CPU cooling' is the only actor
> for thermal (CPU capacity) capping.
> 
> thermal_sys-$(CONFIG_CPU_THERMAL)       += cpu_cooling.o
> 

Hi All,
Thanks for all the reviews!

The other option will be to have a separate
CONFIG_HAVE_SCHED_THERMAL_PRESSURE. This will ensure that we are not
tied to cpu cooling thermal infrastructure. What say?
 There is a CONFIG_HAVE_SCHED_AVG_IRQ for irq load average in pelt.c.


-- 
Warm Regards
Thara

  reply	other threads:[~2019-12-27 15:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12  4:11 [Patch v6 0/7] Introduce Thermal Pressure Thara Gopinath
2019-12-12  4:11 ` [Patch v6 1/7] sched/pelt.c: Add support to track thermal pressure Thara Gopinath
2019-12-16 13:43   ` Peter Zijlstra
2019-12-17 12:54   ` Dietmar Eggemann
     [not found]     ` <CALD-y_xHS7CaZ8SU--VP5+2F5Y8cVb4sw0XuG+JUpP_jxE7yuQ@mail.gmail.com>
2020-01-09 12:24       ` Dietmar Eggemann
2019-12-23 17:56   ` Ionela Voinescu
2020-01-02 14:40     ` Thara Gopinath
2019-12-12  4:11 ` [Patch v6 2/7] sched: Add hook to read per cpu " Thara Gopinath
2019-12-16 14:35   ` Peter Zijlstra
2019-12-17 12:54     ` Dietmar Eggemann
2019-12-12  4:11 ` [Patch v6 3/7] Add infrastructure to store and update instantaneous " Thara Gopinath
2019-12-16 14:37   ` Peter Zijlstra
2019-12-17 12:54   ` Dietmar Eggemann
2019-12-23 17:50   ` Ionela Voinescu
2019-12-12  4:11 ` [Patch v6 4/7] sched/fair: Enable periodic update of average " Thara Gopinath
2019-12-16 14:39   ` Peter Zijlstra
2019-12-16 17:59     ` Quentin Perret
2019-12-17 12:57       ` Dietmar Eggemann
2019-12-27 15:22         ` Thara Gopinath [this message]
2019-12-12  4:11 ` [Patch v6 5/7] sched/fair: update cpu_capacity to reflect " Thara Gopinath
2019-12-17 12:54   ` Dietmar Eggemann
2019-12-23 17:52   ` Ionela Voinescu
2019-12-12  4:11 ` [Patch v6 6/7] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping Thara Gopinath
2019-12-23 17:54   ` Ionela Voinescu
2019-12-12  4:11 ` [Patch v6 7/7] sched/fair: Enable tuning of decay period Thara Gopinath
2019-12-23 17:55   ` Ionela Voinescu
2019-12-16 14:56 ` [Patch v6 0/7] Introduce Thermal Pressure Peter Zijlstra
2020-01-11 15:04   ` Thara Gopinath

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=5E0621A5.5040901@linaro.org \
    --to=thara.gopinath@linaro.org \
    --cc=amit.kachhap@gmail.com \
    --cc=amit.kucheria@verdurent.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=ionela.voinescu@arm.com \
    --cc=javi.merino@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=rui.zhang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome