From: Aboorva Devarajan <aboorvad@linux.ibm.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Linux PM <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Christian Loehle <christian.loehle@arm.com>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
aboorvad@linux.ibm.com
Subject: Re: [RFT][PATCH v1 0/5] cpuidle: menu: Avoid discarding useful information when processing recent idle intervals
Date: Wed, 26 Feb 2025 10:19:14 +0530 [thread overview]
Message-ID: <f949565ef1f256a1641cea3fa1d01d126bcc32e8.camel@linux.ibm.com> (raw)
In-Reply-To: <d0c013d5d2a9251d5dc468446f2a08ae8a7a8953.camel@linux.ibm.com>
On Mon, 2025-02-24 at 11:57 +0530, Aboorva Devarajan wrote:
> On Thu, 2025-02-06 at 15:21 +0100, Rafael J. Wysocki wrote:
>
>
>
>
> So for the entire series:
>
> Tested-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
>
> I'm also trying a minimal unit fuzz-test with the pre- and post- patched version of the get_typical_interval
> function to understand this better, will post the results soon.
>
>
In addition to the previous tests, I also reviewed and tested how get_typical_interval
predicts the idle duration before and after the patch by mimicking the function in
userspace for better unit fuzz testing [1].
With the patch get_typical_interval function now produces more predictable values, whereas
in the previous implementation it frequently returned UINT_MAX. The behavior with the patch
seems to be more reasonable compared to before.
Here are the test results
1. Low Variance:
When the history of CPU idle durations (8 intervals) is relatively uniform with low variance,
the predicted idle duration is unchanged between the patched and unpatched versions:
| Test Case | Intervals | Before | After | Difference |
|-----------|----------------------------------------------|--------|-------|------------|
| 1 | 100,105,110,115,120,125,130,135 | 117 | 117 | 0 |
| 2 | 200,205,210,215,220,225,230,235 | 217 | 217 | 0 |
| 3 | 500,505,510,515,520,525,530,535 | 517 | 517 | 0 |
| 4 | 1000,1005,1010,1015,1020,1025,1030,1035 | 1017 | 1017 | 0 |
2. High Variance
For cases with high variance, the nonpatched function returned UINT_MAX,
After the patch, the function now returns reasonable values:
| Test Case | Intervals | Before | After | Difference |
|-----------|--------------------------------------------|-------------|-------|------------------|
| 5 | 99,198,297,396,495,594,693,792 | 4294967295 | 594 | -4294966701 |
| 6 | 1000,2000,3000,4000,5000,6000,7000,8000 | 4294967295 | 6000 | -4294961295 |
| 7 | 40,140,240,340,440,540,640,740 | 4294967295 | 540 | -4294966755 |
| 8 | 90,590,1090,1590,2090,2590,3090,3590 | 4294967295 | 2590 | -4294964705 |
| 9 | 42,142,242,342,442,542,642,742 | 4294967295 | 542 | -4294966753 |
| 10 | 70,570,1070,1570,2070,2570,3070,3570 | 4294967295 | 2570 | -4294964725 |
| 11 | 44,144,244,344,444,544,644,744 | 4294967295 | 544 | -4294966751 |
3. Low-end Outliers
The patch removes variance from low-end values as well,
Without the patch, the function only filtered high-end outliers, but now it correctly eliminates both
high and low ends.
| Test Case | Intervals | Before | After | Difference |
|-----------|-------------------------------------------|-------------|-------|-------------|
| 12 | 1,200,200,250,250,230,220,260 | 4294967295 | 230 | -4294967065 |
| 13 | 100000,200,200,250,250,230,220,260 | 230 | 230 | 0 |
4. As far as I understand, the function only returns UINT_MAX when all values are 0, negative, or the
computed average itself is UINT_MAX.
| Test Case | Intervals | Before | After | Difference |
|-----------|---------------------------------------------|-------------|-------------|------------|
| 14 | 4294967295,4294967295,4294967295,4294967295 | 4294967295 | 4294967295 | 0 |
| 15 | 0,0,0,0,0,0,0,0 | 4294967295 | 4294967295 | 0 |
The updated get_typical_interval function avoids unnecessary UINT_MAX returns, handles both low and high end
outliers, and gives more reliable predictions in high-variance cases. It only returns UINT_MAX when absolutely
necessary, and this will help in not selecting deeper idle state unless it is needed. So, I'm good with
the patch.
Refer [2] for more test results.
[1] - https://github.com/AboorvaDevarajan/linux-utils/blob/main/cpuidle/cpuidle-predict-duration/predict_cpuidle_interval.c
[2] - https://github.com/AboorvaDevarajan/linux-utils/blob/main/cpuidle/cpuidle-predict-duration/out.predict.csv
Thanks,
Aboorva
next prev parent reply other threads:[~2025-02-26 4:49 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 14:21 [RFT][PATCH v1 0/5] cpuidle: menu: Avoid discarding useful information when processing recent idle intervals Rafael J. Wysocki
2025-02-06 14:22 ` [RFT][PATCH v1 1/5] cpuidle: menu: Drop a redundant local variable Rafael J. Wysocki
2025-02-06 14:55 ` Christian Loehle
2025-02-06 14:24 ` [RFT][PATCH v1 2/5] cpuidle: menu: Use one loop for average and variance computations Rafael J. Wysocki
2025-02-17 13:03 ` Christian Loehle
2025-02-06 14:25 ` [RFT][PATCH v1 3/5] cpuidle: menu: Tweak threshold use in get_typical_interval() Rafael J. Wysocki
2025-02-17 13:08 ` Christian Loehle
2025-02-06 14:26 ` [RFT][PATCH v1 4/5] cpuidle: menu: Eliminate outliers on both ends of the sample set Rafael J. Wysocki
2025-02-17 13:26 ` Christian Loehle
2025-02-06 14:29 ` [RFT][PATCH v1 5/5] cpuidle: menu: Avoid discarding useful information Rafael J. Wysocki
2025-02-17 13:39 ` Christian Loehle
2025-02-17 13:47 ` Rafael J. Wysocki
2025-08-04 16:54 ` Marc Zyngier
2025-08-05 13:23 ` Rafael J. Wysocki
2025-08-05 14:41 ` Christian Loehle
2025-08-05 16:00 ` Marc Zyngier
2025-08-05 18:50 ` Rafael J. Wysocki
2025-08-06 7:19 ` Marc Zyngier
2025-08-06 12:48 ` Christian Loehle
2025-02-07 14:48 ` [RFT][PATCH v1 0/5] cpuidle: menu: Avoid discarding useful information when processing recent idle intervals Artem Bityutskiy
2025-02-07 15:24 ` Christian Loehle
2025-02-07 15:35 ` Rafael J. Wysocki
2025-02-07 15:45 ` Rafael J. Wysocki
2025-03-12 21:38 ` Doug Smythies
2025-02-10 14:15 ` Christian Loehle
2025-02-10 14:43 ` Rafael J. Wysocki
2025-02-10 14:47 ` Christian Loehle
2025-02-18 21:17 ` Christian Loehle
2025-02-19 12:06 ` Rafael J. Wysocki
2025-02-14 4:30 ` Doug Smythies
2025-02-14 22:10 ` Rafael J. Wysocki
2025-02-16 16:16 ` Doug Smythies
2025-02-24 6:27 ` Aboorva Devarajan
2025-02-24 6:38 ` Aboorva Devarajan
2025-02-24 12:35 ` Rafael J. Wysocki
2025-02-26 4:49 ` Aboorva Devarajan [this message]
2025-02-26 10:54 ` Christian Loehle
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f949565ef1f256a1641cea3fa1d01d126bcc32e8.camel@linux.ibm.com \
--to=aboorvad@linux.ibm.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=christian.loehle@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).