LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Cc: linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org,
Kevin Hilman <khilman@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Preeti U Murthy <preeti@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: [PATCH 0/3] clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED
Date: Fri, 27 Mar 2015 22:44:26 +0530 [thread overview]
Message-ID: <cover.1427475606.git.viresh.kumar@linaro.org> (raw)
Hi Thomas/Ingo/Peter,
A clockevent device is used to service timers/hrtimers requests and the next
event (when it should fire) is decided by the timer/hrtimer expiring next. When
no timers/hrtimers are pending to be serviced, the expiry time is set to a
special value: KTIME_MAX.
This would normally happen with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.
When 'expiry == KTIME_MAX', we either cancel the 'tick-sched' hrtimer
(NOHZ_MODE_HIGHRES) or skip reprogramming clockevent device (NOHZ_MODE_LOWRES).
But, the clockevent device is already reprogrammed from the tick-handler for
next tick.
As the clock event device is programmed in ONESHOT mode it will at least fire
one more time (unnecessarily). Timers on few implementations (like
arm_arch_timer, etc.) only support PERIODIC mode and their drivers emulate
ONESHOT over that. Which means that on these platforms we will get spurious
interrupts periodically (at last programmed interval rate, normally tick rate).
In order to avoid spurious interrupts, the clockevent device should be stopped
or its interrupts should be masked.
A simple (yet hacky) solution to get this fixed could be: update
hrtimer_force_reprogram() to always reprogram clockevent device and update
clockevent drivers to STOP generating events (or delay it to max time) when
'expires' is set to KTIME_MAX. But the drawback here is that every clockevent
driver has to be hacked for this particular case and its very easy for new ones
to miss this.
However, Thomas suggested to add an optional state ONESHOT_STOPPED to solve this
problem: lkml.org/lkml/2014/5/9/508.
First patch implements the required infrastructure to start/stop clockevent
device. Third patch stops clockevent devices when no longer required and Second
patch starts them again as and when required.
The review order can be 1,3,2 for better understanding. But patch 2 was required
before 3 to keep 'git bisect' happy, otherwise clockevent device might never get
restarted after stopping it :)
It is also pushed here:
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git tick/oneshot-stopped
Viresh Kumar (3):
clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state
clockevents: Restart clockevent device before using it again
clockevents: Switch state to ONESHOT_STOPPED for unused clockevent
devices
include/linux/clockchips.h | 7 ++++++-
kernel/time/clockevents.c | 18 +++++++++++++++-
kernel/time/hrtimer.c | 51 ++++++++++++++++++++++++++++++++++++++++++----
kernel/time/tick-sched.c | 17 +++++++++++++++-
kernel/time/timer_list.c | 6 ++++++
5 files changed, 92 insertions(+), 7 deletions(-)
--
2.3.0.rc0.44.ga94655d
next reply other threads:[~2015-03-27 17:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 17:14 Viresh Kumar [this message]
2015-03-27 17:14 ` [PATCH 1/3] clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state Viresh Kumar
2015-03-30 5:49 ` Preeti U Murthy
2015-04-06 21:26 ` Kevin Hilman
2015-03-27 17:14 ` [PATCH 2/3] clockevents: Restart clockevent device before using it again Viresh Kumar
2015-03-30 5:52 ` Preeti U Murthy
2015-04-02 13:34 ` Peter Zijlstra
2015-04-02 13:50 ` Viresh Kumar
2015-04-02 15:06 ` Peter Zijlstra
2015-04-02 16:04 ` Ingo Molnar
2015-03-27 17:14 ` [PATCH 3/3] clockevents: Switch state to ONESHOT_STOPPED for unused clockevent devices Viresh Kumar
2015-03-30 5:50 ` Preeti U Murthy
2015-04-02 13:37 ` Peter Zijlstra
2015-04-02 13:51 ` Viresh Kumar
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=cover.1427475606.git.viresh.kumar@linaro.org \
--to=viresh.kumar@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=fweisbec@gmail.com \
--cc=khilman@linaro.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--subject='Re: [PATCH 0/3] clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED' \
/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
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).