From: Marcelo Tosatti <mtosatti@redhat.com>
To: Rik van Riel <riel@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: kernel/timer: avoid spurious ksoftirqd wakeups
Date: Thu, 2 Apr 2015 17:53:28 -0300 [thread overview]
Message-ID: <20150402205328.GA11139@amt.cnet> (raw)
In-Reply-To: <551D4B02.30302@redhat.com>
On Thu, Apr 02, 2015 at 09:58:26AM -0400, Rik van Riel wrote:
> On 04/01/2015 09:44 PM, Marcelo Tosatti wrote:
>
> > +++ b/kernel/time/tick-sched.c
> > @@ -568,6 +568,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > unsigned long rcu_delta_jiffies;
> > struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev);
> > u64 time_delta;
> > + bool raise_softirq;
>
> You may want to initialize this to false. Nothing else
> in the code ever seems to set it to false.
>
> It may work in your test due to that address on the stack
> already being zeroed out due to a lucky coincidence, but
> that is not a guarantee.
>
> > --- a/kernel/time/timer.c
> > +++ b/kernel/time/timer.c
> > @@ -1343,7 +1343,7 @@ static unsigned long cmp_next_hrtimer_event(unsigned long now,
> > * get_next_timer_interrupt - return the jiffy of the next pending timer
> > * @now: current time (in jiffies)
> > */
> > -unsigned long get_next_timer_interrupt(unsigned long now)
> > +unsigned long get_next_timer_interrupt(unsigned long now, bool *raise_softirq)
> > {
> > struct tvec_base *base = __this_cpu_read(tvec_bases);
> > unsigned long expires = now + NEXT_TIMER_MAX_DELTA;
> > @@ -1357,6 +1357,7 @@ unsigned long get_next_timer_interrupt(unsigned long now)
> >
> > spin_lock(&base->lock);
> > if (base->active_timers) {
> > + *raise_softirq = true;
> > if (time_before_eq(base->next_timer, base->timer_jiffies))
> > base->next_timer = __next_timer_interrupt(base);
> > expires = base->next_timer;
>
> Given that run_timer_softirq() only actually does something
> if the timer has expired, would it make sense to only raise
> the softirq after the timer has expired?
jiffies might be increased by tick_nohz_stop_sched_tick.
So you'd have to test again after increasing jiffies.
next prev parent reply other threads:[~2015-04-02 20:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 1:44 kernel/timer: avoid spurious ksoftirqd wakeups Marcelo Tosatti
2015-04-02 13:58 ` Rik van Riel
2015-04-02 20:53 ` Marcelo Tosatti [this message]
2015-04-02 14:59 ` Frederic Weisbecker
2015-04-02 21:08 ` Marcelo Tosatti
2015-04-06 23:34 ` Frederic Weisbecker
2015-04-06 23:51 ` Marcelo Tosatti
2015-04-07 20:17 ` Frederic Weisbecker
2015-04-07 22:29 ` Marcelo Tosatti
[not found] <042301d06cf5$2ec7ae90$8c570bb0$@alibaba-inc.com>
2015-04-02 3:32 ` Hillf Danton
2015-04-02 20:29 ` Marcelo Tosatti
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=20150402205328.GA11139@amt.cnet \
--to=mtosatti@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=riel@redhat.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.