linux-kernel - Re: [Patch v6 4/7] sched/fair: Enable periodic update of average thermal pressure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5E0621A5.5040901@linaro.org>
Date:   Fri, 27 Dec 2019 10:22:13 -0500
From:   Thara Gopinath <thara.gopinath@...aro.org>
To:     Dietmar Eggemann <dietmar.eggemann@....com>,
        Quentin Perret <qperret@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...hat.com, ionela.voinescu@....com,
        vincent.guittot@...aro.org, rui.zhang@...el.com,
        daniel.lezcano@...aro.org, viresh.kumar@...aro.org,
        linux-kernel@...r.kernel.org, amit.kachhap@...il.com,
        javi.merino@...nel.org, amit.kucheria@...durent.com
Subject: Re: [Patch v6 4/7] sched/fair: Enable periodic update of average
 thermal pressure

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