Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling

[Lukasz Luba]

On 2/17/22 4:50 PM, Doug Anderson wrote:
> Hi,
>
> On Wed, Feb 16, 2022 at 3:28 PM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
> > On 2/16/22 5:21 PM, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Tue, Feb 8, 2022 at 1:32 AM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
> > > > >      Another important thing is the consistent scale of the power values
> > > > >      provided by the cooling devices. All of the cooling devices in a single
> > > > >      thermal zone should have power values reported either in milli-Watts
> > > > >      or scaled to the same 'abstract scale'.
> > > >
> > > > This can change. We have removed the userspace governor from kernel
> > > > recently. The trend is to implement thermal policy in FW. Dealing with
> > > > some intermediate configurations are causing complicated design, support
> > > > of the algorithm logic is also more complex.
> > >
> > > One thing that didn't get addressed is the whole "The trend is to
> > > implement thermal policy in FW". I'm not sure I can get on board with
> > > that trend. IMO "moving to FW" isn't a super great trend. FW is harder
> > > to update than kernel and trying to keep it in sync with the kernel
> > > isn't wonderful. Unless something _has_ to be in FW I personally
> > > prefer it to be in the kernel.
> >
> > There are pros and cons for both approaches (as always).
> >
> > Although, there are some use cases, where the kernel is not able to
> > react that fast, e.g. sudden power usage changes, which can cause
> > that the power rail is not able to sustain within required conditions.
> > When we are talking about tough requirements for those power & thermal
> > policies, the mechanism must be fast, precised and reliable.
> >
> > Here you can find Arm reference FW implementation and an IPA clone
> > in there (I have been reviewing this) [1][2].
> >
> > As you can see there is a new FW feature set:
> > "MPMM, Traffic-cop and Thermal management".
> >
> > Apart from Arm implementation, there are already known thermal
> > monitoring mechanisms in HW/FW. Like in the new Qcom SoCs which
> > are using this driver code [3]. The driver receives an interrupt
> > about throttling conditions and just populates the thermal pressure.
>
> Yeah, this has come up in another context recently too. Right on on
> the Qcom SoCs I'm working with (sc7180 on Chromebooks) we've
> essentially disabled all the HW/FW throttling (LMH), preferring to let
> Linux manage things. We chose to do it this way with the assumption
> that Linux would be able to make better decisions than the firmware
> and it was easier to understand / update than an opaque
> vendor-provided blob. LMH is still there with super high limits in
> case Linux goofs up (we don't want to damage the CPU) but it's not the
> primary means of throttling.
>
> As you said, Linux reacts a bit slower, though I've heard that might
> be fixed soon-ish? So far on sc7180 Chromebooks it hasn't been a
> problem because we have more total thermal mass and the CPUs in sc7180
> don't actually generate that much heat compared to other CPUs. We also
> have thermal interrupts enabled, which helps. That being said,
> improvements are certainly welcome!

Thanks Doug for sharing this with me. I'll keep this in mind, your
requirements, configuration and usage.
I've learned recently that some SoCs start throttling very early during
boot, even before the cpumask is available. That was causing
kernel to blow up (deference of a cpumask NULL pointer in that LMH [1]).

[1] 
https://lore.kernel.org/linux-pm/20220128032554.155132-2-bjorn.andersson@xxxxxxxxxx/