From: Frederic Weisbecker <fweisbec@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
James Hartsock <hartsjc@redhat.com>,
Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] nohz: Fix collision between tick and other hrtimers
Date: Thu, 29 Dec 2016 17:53:53 +0100 [thread overview]
Message-ID: <20161229165350.GC2765@lerouge> (raw)
In-Reply-To: <alpine.DEB.2.20.1612290955191.5007@nanos>
On Thu, Dec 29, 2016 at 05:42:48PM +0100, Thomas Gleixner wrote:
> On Sat, 24 Dec 2016, Frederic Weisbecker wrote:
> > static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > ktime_t now, int cpu)
> > {
> > - struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev);
> > u64 basemono, next_tick, next_tmr, next_rcu, delta, expires;
> > unsigned long seq, basejiff;
> > ktime_t tick;
> > @@ -767,7 +766,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > tick.tv64 = expires;
> >
> > /* Skip reprogram of event if its not changed */
> > - if (ts->tick_stopped && (expires == dev->next_event.tv64))
> > + if (ts->tick_stopped && (expires == ts->next_tick.tv64))
> > goto out;
>
> Good catch!
>
> >
> > /*
> > @@ -787,6 +786,8 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > trace_tick_stop(1, TICK_DEP_MASK_NONE);
> > }
> >
> > + ts->next_tick = tick;
> > +
> > /*
> > * If the expiration time == KTIME_MAX, then we simply stop
> > * the tick timer.
> > @@ -803,7 +804,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > tick_program_event(tick, 1);
> > out:
> > /* Update the estimated sleep length */
> > - ts->sleep_length = ktime_sub(dev->next_event, now);
> > + ts->sleep_length = ktime_sub(ts->next_tick, now);
>
> This is wrong. If the next event is earlier than the next estimated tick
> then tick_nohz_get_sleep_length() will return crap and the idle governor
> will go into a deeper C-state than sensible.
Ah I see, the governor wants to know about the next timer, whether it is the tick
or not, right? I'll fix that and improve the comment along.
Thanks.
prev parent reply other threads:[~2016-12-29 16:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-24 16:15 [PATCH] nohz: Fix collision between tick and other hrtimers Frederic Weisbecker
2016-12-26 2:56 ` Rik van Riel
2016-12-26 16:40 ` Frederic Weisbecker
2016-12-26 23:44 ` Wanpeng Li
2016-12-29 16:42 ` Thomas Gleixner
2016-12-29 16:53 ` Frederic Weisbecker [this message]
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=20161229165350.GC2765@lerouge \
--to=fweisbec@gmail.com \
--cc=hartsjc@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
/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