From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
James Hartsock <hartsjc@redhat.com>,
Wanpeng Li <wanpeng.li@hotmail.com>,
Ingo Molnar <mingo@kernel.org>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v2] nohz: Fix collision between tick and other hrtimers
Date: Thu, 5 Jan 2017 12:49:35 +0100 [thread overview]
Message-ID: <20170105114935.GK3093@worktop> (raw)
In-Reply-To: <1483539124-5693-1-git-send-email-fweisbec@gmail.com>
On Wed, Jan 04, 2017 at 03:12:04PM +0100, Frederic Weisbecker wrote:
> When the tick is stopped and an interrupt occurs afterward, we check on
> that interrupt exit if the next tick needs to be rescheduled. If it
> doesn't need any update, we don't want to do anything.
>
> In order to check if the tick needs an update, we compare it against the
> clockevent device deadline. Now that's a problem because the clockevent
> device is at a lower level than the tick itself if it is implemented
> on top of hrtimer.
>
> Every hrtimer share this clockevent device. So comparing the next tick
> deadline against the clockevent device deadline is wrong because the
> device may be programmed for another hrtimer whose deadline collides
> with the tick. As a result we may end up not reprogramming the tick
> accidentally.
>
> In a worst case scenario under full dynticks mode, the tick stops firing
> as it is supposed to every 1hz, leaving /proc/stat stalled:
>
> Task in a full dynticks CPU
> ----------------------------
>
> * hrtimer A is queued 2 seconds ahead
> * the tick is stopped, scheduled 1 second ahead
> * tick fires 1 second later
> * on tick exit, nohz schedules the tick 1 second ahead but sees
> the clockevent device is already programmed to that deadline,
> fooled by hrtimer A, the tick isn't rescheduled.
> * hrtimer A is cancelled before its deadline
> * tick never fires again until an interrupt happens...
>
> In order to fix this, store the next tick deadline to the tick_sched
> local structure and reuse that value later to check whether we need to
> reprogram the clock after an interrupt.
>
> On the other hand, ts->sleep_length still wants to know about the next
> clock event and not just the tick, so we want to improve the related
> comment to avoid confusion.
>
> Acked-by: Rik van Riel <riel@redhat.com>
> Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com>
> Reported-by: James Hartsock <hartsjc@redhat.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Rik van Riel <riel@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
next prev parent reply other threads:[~2017-01-05 11:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-04 14:12 [PATCH v2] nohz: Fix collision between tick and other hrtimers Frederic Weisbecker
2017-01-05 11:49 ` Peter Zijlstra [this message]
2017-01-11 9:46 ` [tip:timers/urgent] " tip-bot for Frederic Weisbecker
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=20170105114935.GK3093@worktop \
--to=peterz@infradead.org \
--cc=fweisbec@gmail.com \
--cc=hartsjc@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=wanpeng.li@hotmail.com \
/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.