linux-kernel - Re: [PATCH v2 1/2] sched/fair: Take thermal pressure into account while estimating energy

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]

Date:   Thu, 10 Jun 2021 11:37:53 +0100
From:   Lukasz Luba <lukasz.luba@....com>
To:     Dietmar Eggemann <dietmar.eggemann@....com>,
        vincent.guittot@...aro.org
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        peterz@...radead.org, rjw@...ysocki.net, viresh.kumar@...aro.org,
        qperret@...gle.com, vincent.donnefort@....com,
        Beata.Michalska@....com, mingo@...hat.com, juri.lelli@...hat.com,
        rostedt@...dmis.org, segall@...gle.com, mgorman@...e.de,
        bristot@...hat.com
Subject: Re: [PATCH v2 1/2] sched/fair: Take thermal pressure into account
 while estimating energy



On 6/10/21 11:07 AM, Dietmar Eggemann wrote:
> On 10/06/2021 11:04, Lukasz Luba wrote:
>>

[snip]

>> Not always, it depends on thermal governor decision, workload and
>> 'power actors' (in IPA naming convention). Then it depends when and how
>> hard you clamp the CPUs. They (CPUs) don't have to be always
>> overutilized, they might be even 50-70% utilized but the GPU reduced
>> power budget by 2 Watts, so CPUs left with only 1W. Which is still OK
>> for the CPUs, since they are only 'feeding' the GPU with new 'jobs'.
> 
> All this pretty much confines the usefulness of you proposed change. A
> precise description of it with the patches is necessary to allow people
> to start from there while exploring your patches.

OK, I see your point.

[snip]

>> True, I hope this description above would help to understand the
>> scenario.
> 
> This description belongs in the patch header. The scenario in which your
> functionality would improve things has to be clear.
> I'm sure that not everybody looking at this patches is immediately aware
> on how IPA setups work and which specific setup you have in mind here.

Agree. I will add this description into the patch header for v3.

[snip]

>>
>> Yes, this code implementation tries to address those issues.
> 
> The point I was making here is: why using the PELT signal
> thermal_load_avg() and not per_cpu(thermal_pressure, cpu) directly,
> given the fact that the latter perfectly represents the frequency clamping?
> 

Good question. I wanted to be aligned with other parts in the fair.c
like cpu_capacity() and all it's users. The CPU capacity is reduced by
RT, DL, IRQ and thermal load avg, not the 'raw' value from the
per-cpu variable.

TBH I cannot recall what was the argument back then
when thermal pressure geometric series was introduced.
Maybe to have a better control how fast it raises and decays
so other mechanisms in the scheduler will see the change in thermal
as not so sharp... (?)


Vincent do you remember the motivation to have geometric series
in thermal pressure and not use just the 'raw' value from per-cpu?