Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <5712331.DvuYhMxLoT@kreacher> <CAJZ5v0jTG-oqV+misnP-=W5aq0S9X631kW9EhKNEn1VJQqwL2g@mail.gmail.com>
 <002201d9ca0c$27606f70$76214e50$@telus.net> <CAJZ5v0gYsH9EKgCO_LESuvd0dcOJLgPrWeN=6V-bY4gq-w1oyA@mail.gmail.com>
 <CAAYoRsWfMTX_ifNG5w9LS50OcPx87yJHg_PSvROoQJJ605eJEA@mail.gmail.com> <4872c41b-c8fd-1f84-7940-d4944c667e6f@linutronix.de>
In-Reply-To: <4872c41b-c8fd-1f84-7940-d4944c667e6f@linutronix.de>
From:   Doug Smythies <dsmythies@telus.net>
Date:   Wed, 9 Aug 2023 17:43:51 -0700
Message-ID: <CAAYoRsXZsbh0o5fTDjjvTN7bS2EQOY9XWwnM8_MGTiwkAS8pYQ@mail.gmail.com>
Subject: Re: [RFT][PATCH v2 0/3] cpuidle: teo: Do not check timers
 unconditionally every time
To:     Anna-Maria Behnsen <anna-maria@linutronix.de>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Frederic Weisbecker <frederic@kernel.org>,
        Linux PM <linux-pm@vger.kernel.org>,
        Kajetan Puchalski <kajetan.puchalski@arm.com>,
        Doug Smythies <dsmythies@telus.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Aug 9, 2023 at 9:24=E2=80=AFAM Anna-Maria Behnsen
<anna-maria@linutronix.de> wrote:
> On Tue, 8 Aug 2023, Doug Smythies wrote:
> > On Tue, Aug 8, 2023 at 9:43=E2=80=AFAM Rafael J. Wysocki <rafael@kernel=
.org> wrote:
> > > On Tue, Aug 8, 2023 at 5:22=E2=80=AFPM Doug Smythies <dsmythies@telus=
.net> wrote:
>
> [...]
>
> > > > 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.
> >
>
> Regarding the compelling reason:
>
> On a fully loaded machine with 256 CPUs tick_nohz_next_event() is execute=
d
> ~48000 times per second. With this patchset it is reduced to ~120 times p=
er
> second. The factor for the difference is 400. This is already an
> improvement.
>
> tick_nohz_next_event() marks timer bases idle, whenever possible - even i=
f
> the tick is not stopped afterwards. When a timer is enqueued remote into =
an
> idle timer base an IPI is sent. Calling tick_nohz_next_event() only when
> the system is not that busy, prevents those unnecessary IPIs.
>
> Beside of those facts, I'm working on the timer pull model [0]. With this=
,
> non pinned timers can also be expired by other CPUs and do not prevent CP=
Us
> from going idle. Those timers will be enqueued on the local CPU without a=
ny
> heuristics. This helps to improve behavior when a system is idle (regardi=
ng
> power). But the call of tick_nohz_next_event() will be more expensive whi=
ch
> led to a regression during testing. This regression is gone with the new
> teo implementation - it seems that there is also an improvement under
> load. I do not have finalized numbers, as it is still WIP (I came across
> some other possible optimizations during analyzing the regression, which
> I'm evaluating at the moment).
>
> Thanks,
>
>         Anna-Maria
>
>
> [0] https://lore.kernel.org/lkml/20230524070629.6377-1-anna-maria@linutro=
nix.de/

Thank you for the context and the link.

... Doug