Hi Lukasz,
On 06/01/2022 12:54, Lukasz Luba wrote:
Hi Daniel,
Could you have a look at this, please?
Yes, I had a quick look at the code and went to the algorithm description.
Still digesting ...
On 12/17/21 6:49 PM, Chetankumar Mistry wrote:
Implement the Ziegler-Nichols Heuristic algorithm to better
estimate the PID Coefficients for a running platform.
The values are tuned to minimuse the amount of overshoot in
the temperature of the platform and subsequently minimise
the number of switches for cdev states.
Signed-off-by: Chetankumar Mistry <chetan.mistry@xxxxxxx>
This is the continuation of the previous idea to have
better k_* values. You might remember this conversation [1].
I've spent some time researching papers how and what can be done
in this field and if possible to plumb in to the kernel.
We had internal discussions (~2017) of one method fuzzy-logic that I
found back then, but died at the begging not fitting into this
IPA kernel specific environment and user-space. Your suggestion with
observing undershooting and overshooting results sparked better idea.
I thought it's worth to invest in it but I didn't have
time. We are lucky, Chetan was designated to help me and
experiment/implement/test these ideas and here is the patch set.
He's chosen the Ziegler-Nichols method, which shows really
good results in benchmarks (Geekbench and GFXbench on hikey960 Android).
The improved performance in Geekbench is ~10% (vs. old IPA).
+10% perf improvements sounds great. What about the temperature
mitigation (temp avg + stddev) ?
The main question from our side is the sysfs interface
which we could be used to trigger this algorithm for
better coefficients estimations.
We ask user to echo to some sysfs files in thermal zone
and start his/her workload. This new IPA 'learns' the system
utilization and reaction in temperature. After a few rounds,
we get better fitted coefficients.
If you need more background about the code or mechanisms, or tests,
I'm sure Chetan is happy to provide you those.
I'm worried about the complexity of the algorithm and the overhead implied.
The k_* factors are tied with the system and the thermal setup (fan,
heatsink, processor, opp, ...). So IIUC when the factors are found, they
should not change and could be part of the system setup.
Would the algorithm fit better in a separate userspace kernel tooling?
So we can run it once and find the k_* for a board.
Additionally, the values can be stored in the Documentation for
different board and a documentation on how to use the tool.
Then up to the SoC vendor to setup the k_* in sysfs, so no need to
change any interface.
If you are interested in those analyses we can find a way to share a> .html file with the results from LISA notebook.
Yes,