Messages in this thread |  | | From | Amit Kucheria <> | Date | Thu, 13 Feb 2020 20:08:02 +0530 | Subject | Re: [Patch v9 3/8] arm,arm64,drivers:Add infrastructure to store and update instantaneous thermal pressure |
| |
On Thu, Feb 13, 2020 at 7:35 PM Thara Gopinath <thara.gopinath@linaro.org> wrote: > > On 02/13/2020 07:25 AM, Amit Kucheria wrote: > > On Wed, Jan 29, 2020 at 4:06 AM Thara Gopinath > > <thara.gopinath@linaro.org> wrote: > >> > >> Add architecture specific APIs to update and track thermal pressure on a > >> per cpu basis. A per cpu variable thermal_pressure is introduced to keep > >> track of instantaneous per cpu thermal pressure. Thermal pressure is the > >> delta between maximum capacity and capped capacity due to a thermal event. > > > > s/capped/decreased to have consistent use throughout the series e.g. in patch 1. > > > > Though personally, I like "capped capacity" in which case > > s/decreased/capped in patch 1 and elsewhere. > > I will fix this > > > >> > >> topology_get_thermal_pressure can be hooked into the scheduler specified > >> arch_cpu_thermal_capacity to retrieve instantaneous thermal pressure of a > >> cpu. > >> > >> arch_set_thermal_pressure can be used to update the thermal pressure. > >> > >> Considering topology_get_thermal_pressure reads thermal_pressure and > >> arch_set_thermal_pressure writes into thermal_pressure, one can argue for > >> some sort of locking mechanism to avoid a stale value. But considering > >> topology_get_thermal_pressure can be called from a system critical path > >> like scheduler tick function, a locking mechanism is not ideal. This means > >> that it is possible the thermal_pressure value used to calculate average > >> thermal pressure for a cpu can be stale for upto 1 tick period. > >> > >> Signed-off-by: Thara Gopinath <thara.gopinath@linaro.org> > >> --- > >> > >> v6->v7: > >> - Changed the input argument in arch_set_thermal_pressure from > >> capped capacity to delta capacity(thermal pressure) as per > >> Ionela's review comments. > >> > >> arch/arm/include/asm/topology.h | 3 +++ > >> arch/arm64/include/asm/topology.h | 3 +++ > > > > Any particular reason to enable this for arm/arm64 in this patch > > itself? I'd have enabled them in two separate patches after this one. > > No reason. No reason not to as well as arch_topology is "Arm specific > cpu topology file" and changes are one-liners.
One reason to do this, IMHO, is to keep platform conversions separate from the core infrastructure in a series, so the core can get merged while platform maintainers can take their time to decide if, when, how to merge this.
|  |