Re: [RFT][PATCH v2 0/3] cpuidle: teo: Do not check timers unconditionally every time

From: Doug Smythies <dsmythies@telus.net>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>,
	Kajetan Puchalski <kajetan.puchalski@arm.com>,
	Doug Smythies <dsmythies@telus.net>
Subject: Re: [RFT][PATCH v2 0/3] cpuidle: teo: Do not check timers unconditionally every time
Date: Tue, 8 Aug 2023 15:40:17 -0700	[thread overview]
Message-ID: <CAAYoRsWfMTX_ifNG5w9LS50OcPx87yJHg_PSvROoQJJ605eJEA@mail.gmail.com> (raw)
In-Reply-To: <CAJZ5v0gYsH9EKgCO_LESuvd0dcOJLgPrWeN=6V-bY4gq-w1oyA@mail.gmail.com>

On Tue, Aug 8, 2023 at 9:43 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Tue, Aug 8, 2023 at 5:22 PM Doug Smythies <dsmythies@telus.net> wrote:
> > On 2023.08.03 14:33 Rafael wrote:
> > > On Thu, Aug 3, 2023 at 11:12 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >>
> > >> Hi Folks,
> > >>
> > >> This is the second iteration of:
> > >>
> > >> https://lore.kernel.org/linux-pm/4511619.LvFx2qVVIh@kreacher/
> > >>
> > >> with an additional patch.
> > >>
> > >> There are some small modifications of patch [1/3] and the new
> > >> patch causes governor statistics to play a role in deciding whether
> > >> or not to stop the scheduler tick.
> > >>
> > >> Testing would be much appreciated!
> > >
> > > For convenience, this series is now available in the following git branch:
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
> > > pm-cpuidle-teo
> >
> > Hi Rafael,
> >
> > Thank you for the git branch link.
> >
> > I did some testing:

... deleted ...

> > Test 2: 6 core ping pong sweep:
> >
> > Pass a token between 6 CPUs on 6 different cores.
> > Do a variable amount of work at each stop.
> >
> > Purpose: To utilize the midrange idle states
> > and observe the transitions from between use of
> > idle states.
> >
> > Results: There is some instability in the results
> > in the early stages.
> > For unknown reasons, the rjw governor sometimes works
> > slower and at lower power. The condition is not 100%
> > repeatable.
> >
> > Overall teo completed the test fastest (54.9 minutes)
> > Followed by menu (56.2 minutes), then rjw (56.7 minutes),
> > then ladder (58.4 minutes). teo is faster throughout the
> > latter stages of the test, but at the cost of more power.
> > The differences seem to be in the transition from idle
> > state 1 to idle state 2 usage.

the magnitude of the later stages differences are significant.

... deleted ...

> Thanks a lot for doing this work, much appreciated!
>
> > Conclusions: Overall, I am not seeing a compelling reason to
> > proceed with this patch set.
>
> On the other hand, if there is a separate compelling reason to do
> that, it doesn't appear to lead to a major regression.

Agreed.

Just for additional information, a 6 core dwell test was run.
The test conditions were cherry picked for dramatic effect:

teo: average: 1162.13 uSec/loop ; Std dev: 0.38
ryw: average: 1266.45 uSec/loop ; Std dev: 6.53 ; +9%

teo: average: 29.98 watts
rjw: average: 30.30 watts
(the same within thermal experimental error)

Details (power and idle stats over the 45 minute test period):
http://smythies.com/~doug/linux/idle/teo-util2/6-13568-147097/perf/