Re: [PATCH v4 10/18] PM: EM: Add RCU mechanism which safely cleans the old data
From: Lukasz Luba
Date: Thu Oct 12 2023 - 09:16:04 EST
On 10/11/23 17:07, Rafael J. Wysocki wrote:
On Wed, Oct 11, 2023 at 6:03 PM Wei Wang <wvw@xxxxxxxxxx> wrote:
On Fri, Oct 6, 2023 at 1:45 AM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
Hi Rafael,
A change of direction here, regarding your comment below.
On 10/2/23 14:44, Lukasz Luba wrote:
On 9/29/23 13:59, Rafael J. Wysocki wrote:
On Fri, Sep 29, 2023 at 11:36 AM Lukasz Luba <lukasz.luba@xxxxxxx> wrote:
[snip]
[snip]
Apparently, some frameworks are only going to use the default table
while the runtime-updatable table will be used somewhere else at the
same time.
I'm not really sure if this is a good idea.
Runtime table is only for driving the task placement in the EAS.
The thermal gov IPA won't make better decisions because it already
has the mechanism to accumulate the error that it made.
The same applies to DTPM, which works in a more 'configurable' way,
rather that hard optimization mechanism (like EAS).
My understanding of the above is that the other EM users don't really
care that much so they can get away with using the default table all
the time, but EAS needs more accuracy, so the table used by it needs
to be adjusted in certain situations.
Yes
Fair enough, I'm assuming that you've done some research around it.
Still, this is rather confusing.
Yes, I have presented those ~2y ago in Android Gerrit world
(got feedback from a few vendors) and in a few Linux conferences.
For now we don't plan to have this feature for the thermal
governor or something similar.
I have discussed with one of our partners your comment about 2 tables.
They would like to have this runtime modified EM in other places
as well: DTPM and thermal governor. So you had good gut feeling.
In the past in our IPA (thermal gov ~2016 and kernel v4.14) we
had two callbacks:
- get_static_power() [1]
- get_dynamic_power() [2]
Later ~2017/2018 v4.16 the static power mechanism was removed
completely by this commit 84fe2cab48590e4373978e4e.
The way how it was design, implemented and used justified that
decision. We later used EM in the cpu cooling which also only
had dynamic power information.
The PID mechanism in IPA tries to compensate that
missing information (about changed static power in time or a chip
binning) and adjusts the 'error'. How good and fast that is in all
situations - it's a different story (out of this scope).
So, IPA should not be worse with the runtime table.
The static power was on the chips and probably will be still.
You might remember my slide 13 from OSPM2024 showing two power
usage plots for the same Big CPU and 1.4GHz fixed (50% of fmax):
- w/ GPU working in the background using 1-1.5W
- w/o GPU in the background
The same workload run on Big, but power bigger is ~15% higher
after ~1min.
The static power (leakage) is the issue that this patch tries
to address for EAS. Although, there is not only the leakage.
It's about the whole 'profile', which can be different than what
could be built during boot default information.
So we would want to go for one single table in EM, which
is runtime modifiable.
That is something that you might be more confident and we would
have less diversity (2 tables) in the kernel.
Regards,
Lukasz
Indeed, we had a conversation about this with Lukasz recently. The key
idea is that there is no compelling reason to introduce diversity in
the mathematics involved. If we have confidence in the superior
accuracy of our model, it should be universally implemented. While the
governors are designed with some error tolerance, they can benefit
from enhanced accuracy in their operation.
I agree, thanks!
Thank you Wei and Rafael. I'm working on that implementation and
will be in v5 soon.