From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: tglx@linutronix.de, peterz@infradead.org, rafael@kernel.org
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
nicolas.pitre@linaro.org, vincent.guittot@linaro.org
Subject: [RFC V2 0/2] IRQ based next prediction
Date: Wed, 20 Jan 2016 17:00:34 +0100 [thread overview]
Message-ID: <1453305636-22156-4-git-send-email-daniel.lezcano@linaro.org> (raw)
In-Reply-To: <1453305636-22156-1-git-send-email-daniel.lezcano@linaro.org>
The current approach to select an idle state is based on the idle period
statistics computation.
Useless to say this approach satisfied everyone as a solution to find the
best trade-off between the performances and the energy saving via the menu
governor.
However, the kernel is evolving to act pro-actively regarding the energy
constraints with the scheduler and the different power management subsystems
are not collaborating with the scheduler as the conductor of the decisions,
they all act independently.
The cpuidle governors are based on idle period statistics, without knowledge
of what woke up the cpu. In these sources of wakes up, the IPI are of course
accounted (as well as the timers irq) which results in doing statistics on
the scheduler behavior too. It is no sense to let the scheduler to take a
decision based on a next prediction of its own decisions.
In order to integrate the cpuidle framework into the scheduler, we have to
radically change the approach by clearly identifying what is causing a wake
up and how it behaves.
This serie inverts the logic.
Instead of tracking the idle durations and do statistics on them, these
patches track the interrupt individually and try to predict the next interrupt.
By combining the interrupts' next event on a single CPU, we can predict the
next event for the CPU, hence predict how long we will be sleeping when
entering idle.
The IPI and timer interrupts are not taken into account.
The first patch provides a callback to be registered in the irq subsystem
and to be called when an interrupt is handled with a timestamp.
The second patch uses the callback provided by the patch above to compute
the delta and store it in a circular buffer. It is per cpu, the callback
implements minimal operations as it is in an interrupt context.
When we the cpu enters idle, it asks for the expected sleep time. Then the
expected minimum sleep length for all interrupts is used and compared to
the timer sleep length, again the minimum is taken and gives the expected
sleep time.
The statistics are very trivial and could be improved later but this first
step shows we have a nice overall improvement in SMP. In UP the menu governor
is a bit better which may indicate the next prediction computation could be
improved but confirms removing the IPI from the equation increase the
accuracy.
Changelog:
V2:
- Changed the register_ops approach for the irq subsystem
- Fixed Nicolas's comments
Daniel Lezcano (2):
irq: Add a framework to measure interrupt timings
sched: idle: IRQ based next prediction for idle period
drivers/cpuidle/Kconfig | 9 +
include/linux/interrupt.h | 26 +++
include/linux/irqhandler.h | 1 +
kernel/irq/Kconfig | 4 +
kernel/irq/handle.c | 1 +
kernel/irq/internals.h | 43 ++++
kernel/irq/irqdesc.c | 6 +
kernel/irq/manage.c | 10 +-
kernel/sched/Makefile | 1 +
kernel/sched/idle-sched.c | 529 +++++++++++++++++++++++++++++++++++++++++++++
10 files changed, 629 insertions(+), 1 deletion(-)
create mode 100644 kernel/sched/idle-sched.c
--
1.9.1
next prev parent reply other threads:[~2016-01-20 16:00 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-06 15:22 [RFC PATCH 0/2] IRQ based next prediction Daniel Lezcano
2016-01-06 15:22 ` [RFC PATCH 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-08 15:31 ` Thomas Gleixner
2016-01-12 11:42 ` Daniel Lezcano
2016-01-06 15:22 ` [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-06 17:40 ` Nicolas Pitre
2016-01-07 15:42 ` Daniel Lezcano
2016-01-12 19:27 ` Nicolas Pitre
2016-01-10 22:37 ` Daniel Lezcano
2016-01-10 22:46 ` Nicolas Pitre
2016-01-10 22:58 ` Daniel Lezcano
2016-01-10 23:13 ` Nicolas Pitre
2016-01-08 15:43 ` Thomas Gleixner
2016-01-12 12:41 ` Daniel Lezcano
2016-01-12 13:42 ` Thomas Gleixner
2016-01-12 14:16 ` Daniel Lezcano
2016-01-12 14:26 ` Thomas Gleixner
2016-01-12 14:52 ` Daniel Lezcano
2016-01-12 15:12 ` Thomas Gleixner
2016-01-12 16:04 ` Daniel Lezcano
2016-01-13 9:17 ` Thomas Gleixner
2016-01-18 13:21 ` Daniel Lezcano
2016-01-20 15:41 ` Thomas Gleixner
2016-01-20 16:00 ` [RFC V2 0/2] IRQ based next prediction Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 17:55 ` Thomas Gleixner
2016-01-21 9:25 ` Daniel Lezcano
2016-01-21 10:27 ` Thomas Gleixner
2016-01-20 19:07 ` Peter Zijlstra
2016-01-20 19:57 ` Thomas Gleixner
2016-01-20 20:04 ` Nicolas Pitre
2016-01-20 20:20 ` Peter Zijlstra
2016-01-20 20:22 ` Thomas Gleixner
2016-01-21 9:50 ` Daniel Lezcano
2016-01-21 10:08 ` Peter Zijlstra
2016-01-21 12:38 ` Daniel Lezcano
2016-01-21 20:27 ` Thomas Gleixner
2016-01-21 13:52 ` Thomas Gleixner
2016-01-21 14:19 ` Daniel Lezcano
2016-01-21 18:56 ` Thomas Gleixner
2016-01-22 10:15 ` Peter Zijlstra
2016-01-21 9:26 ` Daniel Lezcano
2016-01-20 19:28 ` Peter Zijlstra
2016-01-21 9:53 ` Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 17:46 ` Nicolas Pitre
2016-01-20 18:44 ` Peter Zijlstra
2016-01-21 10:03 ` Daniel Lezcano
2016-01-20 19:02 ` Peter Zijlstra
2016-01-20 19:17 ` Nicolas Pitre
2016-01-20 19:29 ` Peter Zijlstra
2016-01-20 19:34 ` Peter Zijlstra
2016-01-20 19:40 ` Peter Zijlstra
2016-01-20 19:57 ` Nicolas Pitre
2016-01-20 20:22 ` Peter Zijlstra
2016-01-20 19:49 ` Thomas Gleixner
2016-01-21 13:54 ` Daniel Lezcano
2016-01-21 14:12 ` Thomas Gleixner
2016-01-20 16:00 ` Daniel Lezcano [this message]
2016-01-20 16:00 ` [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano
2016-01-20 16:00 ` [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano
2016-01-20 20:14 ` Nicolas Pitre
2016-01-21 13:04 ` Daniel Lezcano
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=1453305636-22156-4-git-send-email-daniel.lezcano@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@linaro.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).