Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Doug Smythies" <dsmythies@telus.net>
To:     "'Rafael J. Wysocki'" <rjw@rjwysocki.net>
Cc:     "'Peter Zijlstra'" <peterz@infradead.org>,
        "'Daniel Lezcano'" <daniel.lezcano@linaro.org>,
        "'LKML'" <linux-kernel@vger.kernel.org>,
        "'Giovanni Gherdovich'" <ggherdovich@suse.cz>,
        "'Linux PM'" <linux-pm@vger.kernel.org>
References: <10494959.bKODIZ00nm@kreacher> <000a01d59656$99798710$cc6c9530$@net> <CAJZ5v0gZDJ2=PiiGw2mcCcVKBM2OyM1G9nRvJ+iWLFUQcXqZuw@mail.gmail.com> <6163696.37NBKbymtj@kreacher> <000b01d597f2$06403a50$12c0aef0$@net>
In-Reply-To: <000b01d597f2$06403a50$12c0aef0$@net>
Subject: RE: [PATCH v2] cpuidle: Use nanoseconds as the unit of time
Date:   Sun, 10 Nov 2019 14:12:20 -0800
Message-ID: <002301d59813$ee18c920$ca4a5b60$@net>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-ca
Thread-Index: AdWX66lAJM+ky/tcQb2CPZRo9UbwKwABGLggAANCZjA=
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2019.11.10 10:10 Doug Smythies wrote:
> On 2019.11.10 09:24 Rafael J. Wysocki wrote:
>> On Sunday, November 10, 2019 5:48:21 PM CET Rafael J. Wysocki wrote:
>>
>> I have found a bug, which should be addressed by the patch below.
>>
>> If it still doesn't reduce the discrepancy, we'll need to look further.
>>
>> ---
>> drivers/cpuidle/governors/menu.c |    4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> Index: linux-pm/drivers/cpuidle/governors/menu.c
>> ===================================================================
>> --- linux-pm.orig/drivers/cpuidle/governors/menu.c
>> +++ linux-pm/drivers/cpuidle/governors/menu.c
>> @@ -516,8 +516,8 @@ static void menu_update(struct cpuidle_d
>> 	new_factor -= new_factor / DECAY;
>> 
>> 	if (data->next_timer_ns > 0 && measured_ns < MAX_INTERESTING)
>> -		new_factor += RESOLUTION * div64_u64(measured_ns,
>> -						     data->next_timer_ns);
>> +		new_factor += div64_u64(RESOLUTION * measured_ns,
>> +					data->next_timer_ns);
>> 	else
>> 		/*
>> 		 * we were idle so long that we count it as a perfect
>
> Yes, that was the exact bit of code I focused on yesterday.
> However, my attempt to fix was different, and made no difference,
> with the new graph being exactly on top of the old bad one.
> I had defined new_factor as u64 and RESOLUTION as ULL.

Your patch does fix the problem.
I now also understand why my attempt did not.

New data added to previous graphs. For those that don't
want to go to the graphs, the nanosecond menu graphs are now
almost identical to the microsecond based one.

http://www.smythies.com/~doug/linux/idle/nano-second-conversion/sweep/index.html

Legend:
teo-base : linux-next 2019.11.07
menu-base: linux-next 2019.11.07
teo-v2   : linux-next 2019.11.07 + cpuidle: Consolidate disabled state checks + this v2
menu-v2  : linux-next 2019.11.07 + cpuidle: Consolidate disabled state checks + this v2
rjw1     : menu-v2 + above patch.

Acked-by and tested-by Doug Smythies <dsmythies@telus.net>

Disclaimer: Only teo and menu, not ladder or haltpoll governors.

Additional suggestions:

Header comments:

> microseconds provided by drivers.  In addition to that, change
> cpuidle_governor_latency_req() to return the idle state exit
> latency constraint in nanoseconds.

Suggest:

microseconds provided by drivers.  Additionally, change
cpuidle_governor_latency_req() to return the idle state exit
latency constraint in nanoseconds.

> With that, meeasure idle state residency (last_residency_ns in
             ^^^^^^^^
Suggest:

Also measure idle state residency (last_residency_ns in

Code:
Suggest deletion of this note:

/*
 * Please note when changing the tuning values:
 * If (MAX_INTERESTING-1) * RESOLUTION > UINT_MAX, the result of
 * a scaling operation multiplication may overflow on 32 bit platforms.
 * In that case, #define RESOLUTION as ULL to get 64 bit result:
 * #define RESOLUTION 1024ULL
 *
 * The default values do not overflow.
 */

Because you have managed the extra bit requirements as part of the patch.

... Doug