From: Lukasz Luba <email@example.com>
To: "Rafael J. Wysocki" <firstname.lastname@example.org>
Cc: Linux Kernel Mailing List <email@example.com>,
Daniel Lezcano <firstname.lastname@example.org>,
Linux PM <email@example.com>,
Amit Kucheria <firstname.lastname@example.org>,
"Zhang, Rui" <email@example.com>,
Dietmar Eggemann <firstname.lastname@example.org>,
Chris Redpath <Chris.Redpath@arm.com>,
Beata.Michalska@arm.com, Viresh Kumar <email@example.com>,
"Rafael J. Wysocki" <firstname.lastname@example.org>,
Amit Kachhap <email@example.com>
Subject: Re: [RFC PATCH 2/4] cpuidle: Add Active Stats calls tracking idle entry/exit
Date: Tue, 22 Jun 2021 16:02:00 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 6/22/21 3:44 PM, Rafael J. Wysocki wrote:
> On Tue, Jun 22, 2021 at 3:59 PM Lukasz Luba <email@example.com> wrote:
>> On 6/22/21 1:33 PM, Rafael J. Wysocki wrote:
>>> On Tue, Jun 22, 2021 at 9:59 AM Lukasz Luba <firstname.lastname@example.org> wrote:
>>>> The Active Stats framework tracks and accounts the activity of the CPU
>>>> for each performance level. It accounts the real residency,
>>> No, it doesn't. It just measures the time between the entry and exit
>>> and that's not the real residency (because it doesn't take the exit
>>> latency into account, for example).
>> It's 'just' a 'model' and as other models has limitations, but it's
>> better than existing one, which IPA has to use:
>> cpu_util + currect_freq_at_sampling_time
> But the idle duration is already measured by cpuidle as
> last_residency_ns. Why does it need to be measured once more in
> addition to that?
So the last_residency_ns calculation is done when the CPU is
exiting idle. I need something more, consider this scenario:
IPA wakes up every 100ms and estimates power used in past 100ms.
If one CPU entered idle and is still there for 30ms, then my Active
Stats will tell me this. The last_residency_ns mechanism won't,
since it available when CPU is woken up (I don't want to wake up CPUs).
>>>> when the CPU was not idle, at a given performance level. This patch adds needed calls
>>>> which provide the CPU idle entry/exit events to the Active Stats
>>> And it adds overhead to overhead-sensitive code.
>>> AFAICS, some users of that code will not really get the benefit, so
>>> adding the overhead to it is questionable.
>>> First, why is the existing instrumentation in the idle loop insufficient?
>> The instrumentation (tracing) cannot be used at run time AFAIK. I need
>> this idle + freq information combined in a running platform, not for
>> post-processing (like we have in LISA). The thermal governor IPA would
>> use them for used power estimation.
> What about snapshotting last_residency_ns in the CPU wakeup path?
That would be available in the exit path, for running CPUs only.
>>> Second, why do you need to add locking to this code?
>> The idle entry/exit updates the CPU's accounting data structure.
>> There is a reader of those data structures: thermal governor,
>> run from different CPU, which is the reason why I put locking for them.
> So please consider doing it in a lockless manner and avoid running
> this code when it is not needed in the first place.
I'll have a look at this option.
next prev parent reply other threads:[~2021-06-22 15:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 7:59 [RFC PATCH 0/4] Introduce Active Stats framework with CPU performance statistics Lukasz Luba
2021-06-22 7:59 ` [RFC PATCH 1/4] PM: Introduce Active Stats framework Lukasz Luba
2021-06-22 7:59 ` [RFC PATCH 2/4] cpuidle: Add Active Stats calls tracking idle entry/exit Lukasz Luba
2021-06-22 12:33 ` Rafael J. Wysocki
2021-06-22 13:58 ` Lukasz Luba
2021-06-22 14:44 ` Rafael J. Wysocki
2021-06-22 15:02 ` Lukasz Luba [this message]
2021-06-22 7:59 ` [RFC PATCH 3/4] cpufreq: Add Active Stats calls tracking frequency changes Lukasz Luba
2021-06-22 9:32 ` Viresh Kumar
2021-06-22 11:07 ` Lukasz Luba
2021-06-23 3:15 ` Viresh Kumar
2021-06-23 9:14 ` Lukasz Luba
2021-06-22 12:28 ` Rafael J. Wysocki
2021-06-22 13:42 ` Lukasz Luba
2021-06-22 13:51 ` Rafael J. Wysocki
2021-06-22 14:09 ` Lukasz Luba
2021-06-22 14:51 ` Rafael J. Wysocki
2021-06-22 14:59 ` Rafael J. Wysocki
2021-06-22 15:10 ` Lukasz Luba
2021-06-22 15:02 ` Lukasz Luba
2021-06-22 7:59 ` [RFC PATCH 4/4] thermal: cpufreq_cooling: Improve power estimation based on Active Stats framework Lukasz Luba
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).