linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).