[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0gu=rALS9ZLNMDT3cw_sT2m8XCKP6+AW3488x2Q9EXM3g@mail.gmail.com>
Date: Tue, 1 Oct 2019 11:31:32 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Doug Smythies <dsmythies@...us.net>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
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 Sun, Sep 29, 2019 at 6:05 PM Doug Smythies <dsmythies@...us.net> wrote:
>
> 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.
Thanks for this work!
Please also note that there is a teo patch in 5.4-rc1 that may make a
difference in principle.
Powered by blists - more mailing lists