From: Kevin Hilman <khilman@kernel.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Preeti U Murthy <preeti@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 1/3] clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state
Date: Mon, 06 Apr 2015 14:26:43 -0700 [thread overview]
Message-ID: <7h1tjxx818.fsf@deeprootsystems.com> (raw)
In-Reply-To: <c283d8555b670c4952ceef5782ebe743fbd8a373.1427475606.git.viresh.kumar@linaro.org> (Viresh Kumar's message of "Fri, 27 Mar 2015 22:44:27 +0530")
Viresh Kumar <viresh.kumar@linaro.org> writes:
> When no timers/hrtimers are pending, the expiry time is set to a special value:
> 'KTIME_MAX'. This normally happens 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.
>
> This patch adds support for ONESHOT_STOPPED state in clockevents core. It will
> only be available to drivers that implement the state-specific callbacks instead
> of the legacy ->set_mode() callback.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
with a minor nit...
[...]
> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> index 73689df1e4b8..04f6c3433f8e 100644
> --- a/kernel/time/clockevents.c
> +++ b/kernel/time/clockevents.c
> @@ -138,6 +138,17 @@ static int __clockevents_set_state(struct clock_event_device *dev,
> return -ENOSYS;
> return dev->set_state_oneshot(dev);
>
> + case CLOCK_EVT_STATE_ONESHOT_STOPPED:
> + /* Core internal bug */
This comment is not useful at all (nor are all the other ones already in
this file.) IMO, the comment should say something like:
"ONESHOT_STOPPED is only valid when currently in the ONESHOT state." or
something similar.
> + if (WARN_ONCE(dev->state != CLOCK_EVT_STATE_ONESHOT,
> + "Current state: %d\n", dev->state))
Similarily this output will not be useful, and should say something
like: "Can only enter ONESHOT_STOPPED from ONESHOT. Current state: %d\n".
> + return -EINVAL;
> +
> + if (dev->set_state_oneshot_stopped)
> + return dev->set_state_oneshot_stopped(dev);
> + else
> + return -ENOSYS;
> +
> default:
> return -ENOSYS;
> }
Kevin
next prev parent reply other threads:[~2015-04-06 21:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 17:14 [PATCH 0/3] clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED Viresh Kumar
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 [this message]
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=7h1tjxx818.fsf@deeprootsystems.com \
--to=khilman@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=fweisbec@gmail.com \
--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 \
--cc=viresh.kumar@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.