From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
g@hirez.programming.kicks-ass.net
Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>,
Frederic Weisbecker <frederic@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Valentin Schneider <vschneid@redhat.com>
Subject: Re: Stopping the tick on a fully loaded system
Date: Wed, 26 Jul 2023 18:14:32 +0200 [thread overview]
Message-ID: <20230726161432.GW4253@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJZ5v0iW=kg4i1Fi_Fny=CaH_YKiGps+6KsBPcgWzS5YOk00VA@mail.gmail.com>
On Wed, Jul 26, 2023 at 05:53:46PM +0200, Rafael J. Wysocki wrote:
> > > That means we don't track nearly enough data to reliably tell anything
> > > about disabling the tick or not. We should have at least one bucket
> > > beyond TICK_NSEC for this.
> >
> > Quite likely.
>
> So the reasoning here was that those additional bins would not be
> necessary for idle state selection, but the problem of whether or not
> to stop the tick is kind of separate from the idle state selection
> problem if the target residency values for all of the idle states are
> relatively short. And so it should be addressed separately which
> currently it is not. Admittedly, this is a mistake.
Right, the C state buckets are enough to pick a state, but not to handle
the tick thing.
The below hack boots on my ivb-ep with extra (disabled) states. Now let
me go hack up teo to make use of that.
name residency
POLL 0
C1 1
C1E 80
C3 156
C6 300
TICK 1000
POST-TICK 2000
---
diff --git a/drivers/cpuidle/driver.c b/drivers/cpuidle/driver.c
index d9cda7f6ccb9..5f435fb8b89f 100644
--- a/drivers/cpuidle/driver.c
+++ b/drivers/cpuidle/driver.c
@@ -147,13 +147,37 @@ static void cpuidle_setup_broadcast_timer(void *arg)
tick_broadcast_disable();
}
+static int tick_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ return -ENODEV;
+}
+
+static void __cpuidle_state_init_tick(struct cpuidle_state *s)
+{
+ strcpy(s->name, "TICK");
+ strcpy(s->desc, "(no-op)");
+
+ s->target_residency_ns = TICK_NSEC;
+ s->target_residency = div_u64(TICK_NSEC, NSEC_PER_USEC);
+
+ s->exit_latency_ns = 0;
+ s->exit_latency = 0;
+
+ s->flags |= CPUIDLE_FLAG_UNUSABLE;
+
+ s->enter = tick_enter;
+ s->enter_s2idle = tick_enter;
+}
+
/**
* __cpuidle_driver_init - initialize the driver's internal data
* @drv: a valid pointer to a struct cpuidle_driver
*/
static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{
- int i;
+ int tick = 0, post_tick = 0, i;
/*
* Use all possible CPUs as the default, because if the kernel boots
@@ -192,6 +216,39 @@ static void __cpuidle_driver_init(struct cpuidle_driver *drv)
s->exit_latency_ns = 0;
else
s->exit_latency = div_u64(s->exit_latency_ns, NSEC_PER_USEC);
+
+ if (!tick && s->target_residency_ns >= TICK_NSEC) {
+ tick = 1;
+
+ if (s->target_residency_ns == TICK_NSEC)
+ continue;
+
+ post_tick = 1;
+
+ memmove(&drv->states[i+1], &drv->states[i],
+ sizeof(struct cpuidle_state) * (CPUIDLE_STATE_MAX - i - 1));
+ drv->state_count++;
+
+ __cpuidle_state_init_tick(s);
+ i++;
+ }
+ }
+
+ if (!tick) {
+ struct cpuidle_state *s = &drv->states[i];
+ __cpuidle_state_init_tick(s);
+ drv->state_count++;
+ i++;
+ }
+
+ if (!post_tick) {
+ struct cpuidle_state *s = &drv->states[i];
+ __cpuidle_state_init_tick(s);
+ strcpy(s->name, "POST-TICK");
+ s->target_residency_ns *= 2;
+ s->target_residency *= 2;
+ drv->state_count++;
+ i++;
}
}
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 3183aeb7f5b4..a642ee9e916c 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -16,7 +16,7 @@
#include <linux/hrtimer.h>
#include <linux/context_tracking.h>
-#define CPUIDLE_STATE_MAX 10
+#define CPUIDLE_STATE_MAX 16
#define CPUIDLE_NAME_LEN 16
#define CPUIDLE_DESC_LEN 32
next prev parent reply other threads:[~2023-07-26 19:55 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-20 6:51 Stopping the tick on a fully loaded system Anna-Maria Behnsen
2023-07-20 7:38 ` Vincent Guittot
2023-07-20 13:00 ` Anna-Maria Behnsen
2023-07-20 13:55 ` Vincent Guittot
2023-07-23 21:21 ` Frederic Weisbecker
2023-07-24 8:23 ` Rafael J. Wysocki
2023-07-25 13:07 ` Anna-Maria Behnsen
2023-07-25 14:27 ` Rafael J. Wysocki
2023-07-25 22:28 ` Peter Zijlstra
2023-07-26 15:10 ` Rafael J. Wysocki
2023-07-26 15:53 ` Rafael J. Wysocki
2023-07-26 16:14 ` Peter Zijlstra [this message]
2023-07-26 16:49 ` Peter Zijlstra
2023-07-26 21:26 ` Peter Zijlstra
2023-07-27 7:59 ` Peter Zijlstra
2023-07-27 20:10 ` Rafael J. Wysocki
2023-07-26 16:40 ` Anna-Maria Behnsen
2023-07-26 18:30 ` Rafael J. Wysocki
2023-07-26 20:09 ` Peter Zijlstra
2023-07-26 10:59 ` Frederic Weisbecker
2023-07-26 15:07 ` Rafael J. Wysocki
2023-07-26 10:47 ` Frederic Weisbecker
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=20230726161432.GW4253@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=anna-maria@linutronix.de \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=g@hirez.programming.kicks-ass.net \
--cc=gautham.shenoy@amd.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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