linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anna-Maria Behnsen <anna-maria@linutronix.de>
To: Doug Smythies <dsmythies@telus.net>
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>
Subject: Re: [RFT][PATCH v2 0/3] cpuidle: teo: Do not check timers unconditionally every time
Date: Wed, 9 Aug 2023 18:24:45 +0200 (CEST)	[thread overview]
Message-ID: <4872c41b-c8fd-1f84-7940-d4944c667e6f@linutronix.de> (raw)
In-Reply-To: <CAAYoRsWfMTX_ifNG5w9LS50OcPx87yJHg_PSvROoQJJ605eJEA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

Hi,

On Tue, 8 Aug 2023, Doug Smythies wrote:
> 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:

[...]

> > > 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 executed
~48000 times per second. With this patchset it is reduced to ~120 times per
second. The factor for the difference is 400. This is already an
improvement.

tick_nohz_next_event() marks timer bases idle, whenever possible - even if
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 CPUs
from going idle. Those timers will be enqueued on the local CPU without any
heuristics. This helps to improve behavior when a system is idle (regarding
power). But the call of tick_nohz_next_event() will be more expensive which
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@linutronix.de/

  reply	other threads:[~2023-08-09 16:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 20:57 [RFT][PATCH v2 0/3] cpuidle: teo: Do not check timers unconditionally every time Rafael J. Wysocki
2023-08-03 21:07 ` [RFT][PATCH v2 1/3] cpuidle: teo: Do not call tick_nohz_get_sleep_length() upfront Rafael J. Wysocki
2023-08-03 21:09 ` [RFT][PATCH v2 2/3] cpuidle: teo: Skip tick_nohz_get_sleep_length() call in some cases Rafael J. Wysocki
2023-08-11  8:52   ` Anna-Maria Behnsen
2023-08-11  9:40     ` Rafael J. Wysocki
2023-08-03 21:11 ` [RFT][PATCH v2 3/3] cpuidle: teo: Gather statistics regarding whether or not to stop the tick Rafael J. Wysocki
2023-08-03 21:33 ` [RFT][PATCH v2 0/3] cpuidle: teo: Do not check timers unconditionally every time Rafael J. Wysocki
2023-08-07 15:38   ` Anna-Maria Behnsen
2023-08-07 15:39     ` Anna-Maria Behnsen
2023-08-07 16:47     ` Rafael J. Wysocki
2023-08-09 15:09       ` Anna-Maria Behnsen
2023-08-09 15:11         ` Rafael J. Wysocki
2023-08-08 15:22   ` Doug Smythies
2023-08-08 16:43     ` Rafael J. Wysocki
2023-08-08 22:40       ` Doug Smythies
2023-08-09 16:24         ` Anna-Maria Behnsen [this message]
2023-08-10  0:43           ` Doug Smythies
2023-08-10  1:08         ` Doug Smythies
2023-08-10  7:27           ` Rafael J. Wysocki
2023-08-07 14:00 ` Kajetan Puchalski
2023-08-07 16:46   ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4872c41b-c8fd-1f84-7940-d4944c667e6f@linutronix.de \
    --to=anna-maria@linutronix.de \
    --cc=dsmythies@telus.net \
    --cc=frederic@kernel.org \
    --cc=kajetan.puchalski@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).