Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [Patch v9 7/8] sched/fair: Enable tuning of decay period
To:     Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Peter Zijlstra <peterz@infradead.org>
References: <1580250967-4386-1-git-send-email-thara.gopinath@linaro.org>
 <1580250967-4386-8-git-send-email-thara.gopinath@linaro.org>
 <4eb10687-1a62-cee3-7285-3f50cc023071@infradead.org>
 <5E380D1D.7020500@linaro.org>
 <20200203155549.GL14914@hirez.programming.kicks-ass.net>
 <cc83634f-b3af-6024-7f89-9b231b153070@arm.com> <5E3DE7CC.3060300@linaro.org>
 <c7f299bb-5302-9bfb-2356-61b4c856bd2e@arm.com>
Cc:     Randy Dunlap <rdunlap@infradead.org>, mingo@redhat.com,
        ionela.voinescu@arm.com, vincent.guittot@linaro.org,
        rui.zhang@intel.com, qperret@google.com, daniel.lezcano@linaro.org,
        viresh.kumar@linaro.org, rostedt@goodmis.org, will@kernel.org,
        catalin.marinas@arm.com, sudeep.holla@arm.com,
        juri.lelli@redhat.com, corbet@lwn.net,
        linux-kernel@vger.kernel.org, amit.kachhap@gmail.com,
        javi.merino@kernel.org, amit.kucheria@verdurent.com
From:   Thara Gopinath <thara.gopinath@linaro.org>
Message-ID: <5E455533.3000600@linaro.org>
Date:   Thu, 13 Feb 2020 08:54:59 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <c7f299bb-5302-9bfb-2356-61b4c856bd2e@arm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 02/10/2020 06:59 AM, Dietmar Eggemann wrote:
> On 07/02/2020 23:42, Thara Gopinath wrote:
>> On 02/04/2020 03:39 AM, Dietmar Eggemann wrote:
>>> On 03/02/2020 16:55, Peter Zijlstra wrote:
>>>> On Mon, Feb 03, 2020 at 07:07:57AM -0500, Thara Gopinath wrote:
>>>>> On 01/28/2020 06:56 PM, Randy Dunlap wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 1/28/20 2:36 PM, Thara Gopinath wrote:
> 
> [...]
> 
>>> I do agree. IMHO, there are just two little things outstanding:
>>>
>>> (1) arch_scale_thermal_pressure() instead  of
>>>     arch_cpu_thermal_pressure() in v8 4/7
>>
>> The "scale_" part was discussed in v6. Ionela had suggested that having
>> "scale" is not suited for this function because "thermal pressure" is
>> not exactly scaled but subtracted. I actually agree with that.
>>
>> https://lore.kernel.org/lkml/20191223175005.GA31446@arm.com/
>>
>> Having said that if everyone feel the same about naming of this
>> function, I can change it one last time.
> 
> I'm still in favor for this. And Vincent seems to be OK as well:
> 
> https://lore.kernel.org/r/CAKfTPtBzoLnvAJ7sjPogMYS=WwBbdzWO07Kj=KDFVpO4=Su5ow@mail.gmail.com
> 
> The 'v6->v7' change note:
> 
> - Renamed arch_scale_thermal_capacity to arch_cpu_thermal_pressure
>   as per review comments from Peter, Dietmar and Ionela.
> 
> is really not saying from which review comment the individual changes in
> the function name are coming from. And I don't see an answer to Ionela's
> email saying that her proposal will manifest in a particular part of
> this change.
Hi Dietmar,

Like I said, don't want to argue on name. It is trivial for me. I have
v10 prepped with the name change. Will send it out shortly.

> 
>>> (2) guarding of thermal pressure code in Arm's arch_topology driver  w/
>>>     CONFIG_HAVE_SCHED_THERMAL_PRESSURE plus disabling it by default for
>>>     Arm64.
>> It was enabled by default as per your suggestion in v9.
>>
>> The patch can be dropped.
>>
>> I don't understand the need to guard arch_topology with
>> CONFIG_HAVE_SCHED_THERMAL_PRESSURE. CONFIG_HAVE_SCHED_THERMAL_PRESSURE
>> is for scheduler to enable/disable averaging of thermal pressure. We
>> wanted to separate updating and retrieving of instantaneous thermal
>> pressure from scheduler. Guarding it with
>> CONFIG_HAVE_SCHED_THERMAL_PRESSURE is to me equivalent to putting back
>> this whole code in the scheduler framework. I am against it. I also do
>> not see other arch_ functions guarded similarly.
> 
> Cpu-invariant accounting can't be guarded with a kernel CONFIG switch.
> Frequency-invariant accounting could be with CONFIG_CPU_FREQ but this is
> enabled by default by Arm64 defconfig.
> Thermal pressure (accounting) (CONFIG_HAVE_SCHED_THERMAL_PRESSURE) is
> disabled by default so why should a per-cpu thermal_pressure be
> maintained on such a system (CONFIG_CPU_THERMAL=y by default)?

I agree that there is no need for per-cpu thermal pressure to be
maintained if no averaging is happening in the scheduler, today. I don't
know if there will ever be an use for it.
My issue has to do with using a config option meant for internal
scheduler code being used else where. To me, once this happens, the
entire work done to separate out reading and writing of instantaneous
thermal pressure to arch_topology makes no sense. We could have kept it
in scheduler itself.
Another way I think about this whole thermal pressure framework  is that
it is the job of cooling device or cpufreq or any other entity to update
a throttle in maximum pressure to the scheduler. It should be
independent of what scheduler does with it. Scheduler can choose to
ignore it.

> 


-- 
Warm Regards
Thara