[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000f01d576df$a6b87a30$f4296e90$@net>
Date: Sun, 29 Sep 2019 09:04:56 -0700
From: "Doug Smythies" <dsmythies@...us.net>
To: "'Rafael J. Wysocki'" <rjw@...ysocki.net>
Cc: "'Srinivas Pandruvada'" <srinivas.pandruvada@...ux.intel.com>,
"'Peter Zijlstra'" <peterz@...radead.org>,
"'LKML'" <linux-kernel@...r.kernel.org>,
"'Frederic Weisbecker'" <frederic@...nel.org>,
"'Mel Gorman'" <mgorman@...e.de>,
"'Daniel Lezcano'" <daniel.lezcano@...aro.org>,
"'Chen, Hu'" <hu1.chen@...el.com>,
"'Quentin Perret'" <quentin.perret@....com>,
"'Linux PM'" <linux-pm@...r.kernel.org>,
"'Giovanni Gherdovich'" <ggherdovich@...e.cz>
Subject: RE: [RFC/RFT][PATCH v8] cpuidle: New timer events oriented governor for tickless systems
On 2019.09.26 09:32 Doug Smythies wrote:
> If the deepest idle state is disabled, the system
> can become somewhat unstable, with anywhere between no problem
> at all, to the occasional temporary jump using a lot more
> power for a few seconds, to a permanent jump using a lot more
> power continuously. I have been unable to isolate the exact
> test load conditions under which this will occur. However,
> temporarily disabling and then enabling other idle states
> seems to make for a somewhat repeatable test. It is important
> to note that the issue occurs with only ever disabling the deepest
> idle state, just not reliably.
>
> I want to know how you want to proceed before I do a bunch of
> regression testing.
I did some regression testing anyhow, more to create and debug
a methodology than anything else.
> On 2018.12.11 03:50 Rafael J. Wysocki wrote:
>
>> v7 -> v8:
>> * Apply the selection rules to the idle deepest state as well as to
>> the shallower ones (the deepest idle state was treated differently
>> before by mistake).
>> * Subtract 1/2 of the exit latency from the measured idle duration
>> in teo_update() (instead of subtracting the entire exit latency).
>> This makes the idle state selection be slightly more performance-
>> oriented.
>
> I have isolated the issue to a subset of the v7 to v8 changes, however
> it was not the exit latency changes.
>
> The partial revert to V7 changes I made were (on top of 5.3):
The further testing showed a problem or two with my partial teo-v7 reversion
(I call it teo-v12) under slightly different testing conditions.
I also have a 5.3 based kernel with the current teo reverted and the entire
teo-v7 put in its place. I have yet to find a idle state disabled related issue
with this kernel.
I'll come back to this thread at a later date with better details and test results.
... Doug
Powered by blists - more mailing lists