From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thara Gopinath Subject: Re: [RFC PATCH 0/7] Introduce thermal pressure Date: Wed, 10 Oct 2018 13:08:22 -0400 Message-ID: <5BBE3206.2010407@linaro.org> References: <20181010082933.4ful4dzk7rkijcwu@queper01-lin> <20181010095459.orw2gse75klpwosx@queper01-lin> <20181010103623.ttjexasymdpi66lu@queper01-lin> <20181010122348.GL9130@localhost.localdomain> <20181010125033.GP9130@localhost.localdomain> <20181010133443.GR9130@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20181010133443.GR9130@localhost.localdomain> Sender: linux-kernel-owner@vger.kernel.org To: Juri Lelli , Vincent Guittot Cc: Quentin Perret , Ingo Molnar , linux-kernel , Ingo Molnar , Peter Zijlstra , Zhang Rui , "gregkh@linuxfoundation.org" , "Rafael J. Wysocki" , Amit Kachhap , viresh kumar , Javi Merino , Eduardo Valentin , Daniel Lezcano , "open list:THERMAL" , Ionela Voinescu List-Id: linux-pm@vger.kernel.org On 10/10/2018 09:34 AM, Juri Lelli wrote: > On 10/10/18 15:08, Vincent Guittot wrote: >> On Wed, 10 Oct 2018 at 14:50, Juri Lelli wrote: >>> >>> On 10/10/18 14:34, Vincent Guittot wrote: >>>> Hi Juri, >>>> >>>> On Wed, 10 Oct 2018 at 14:23, Juri Lelli wrote: >>>>> >>>>> On 10/10/18 14:04, Vincent Guittot wrote: >>>>> >>>>> [...] >>>>> >>>>>> The problem was the same with RT, the cfs utilization was lower than >>>>>> reality because RT steals soem cycle to CFS >>>>>> So schedutil was selecting a lower frequency when cfs was running >>>>>> whereas the CPU was fully used. >>>>>> The same can happen with thermal: >>>>>> cap the max freq because of thermal >>>>>> the utilization with decrease. >>>>>> remove the cap >>>>>> the utilization is still low and you will select a low OPP because you >>>>>> don't take into account cycle stolen by thermal like with RT >>>>> >>>>> What if we scale frequency component considering the capped temporary >>>>> max? >>>> >>>> Do you mean using a kind of scale_thermal_capacity in accumulate_sum >>>> when computing utilization ? >>> >>> Yeah, something like that I guess. So that we account for temporary >>> "fake" 1024.. >> >> But the utilization will not be invariant anymore across the system > > Mmm, I guess I might be wrong, but I was thinking we should be able to > deal with this similarly to what we do with cpus with different max > capacities. So, another factor? Because then, how do we handle other > ways in which max freq can be restricted (e.g. from userspace as Javi > was also mentioning)? IMHO, user-space restrictions should be handled separately. It should probably reflect as an update of capacity_orig and rebuilding of scheduler structures as such a restriction is meant to stay for a long duration. Regards Thara > -- Regards Thara