From: Thomas Gleixner <tglx@linutronix.de>
To: Nicholas Piggin <npiggin@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
paulmck@kernel.org, Zhouyi Zhou <zhouzhouyi@gmail.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
linux-kernel@vger.kernel.org, rcu <rcu@vger.kernel.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re:
Date: Fri, 22 Apr 2022 17:53:24 +0200 [thread overview]
Message-ID: <87fsm55d3f.ffs@tglx> (raw)
In-Reply-To: <1649818529.j46672mh2p.astroid@bobo.none>
On Wed, Apr 13 2022 at 15:11, Nicholas Piggin wrote:
> So we traced the problem down to possibly a misunderstanding between
> decrementer clock event device and core code.
>
> The decrementer is only oneshot*ish*. It actually needs to either be
> reprogrammed or shut down otherwise it just continues to cause
> interrupts.
I always thought that PPC had sane timers. That's really disillusioning.
> Before commit 35de589cb879, it was sort of two-shot. The initial
> interrupt at the programmed time would set its internal next_tb variable
> to ~0 and call the ->event_handler(). If that did not set_next_event or
> stop the timer, the interrupt will fire again immediately, notice
> next_tb is ~0, and only then stop the decrementer interrupt.
>
> So that was already kind of ugly, this patch just turned it into a hang.
>
> The problem happens when the tick is stopped with an event still
> pending, then tick_nohz_handler() is called, but it bails out because
> tick_stopped == 1 so the device never gets programmed again, and so it
> keeps firing.
>
> How to fix it? Before commit a7cba02deced, powerpc's decrementer was
> really oneshot, but we would like to avoid doing that because it requires
> additional programming of the hardware on each timer interrupt. We have
> the ONESHOT_STOPPED state which seems to be just about what we want.
>
> Did the ONESHOT_STOPPED patch just miss this case, or is there a reason
> we don't stop it here? This patch seems to fix the hang (not heavily
> tested though).
This was definitely overlooked, but it's arguable it is is not required
for real oneshot clockevent devices. This should only handle the case
where the interrupt was already pending.
The ONESHOT_STOPPED state was introduced to handle the case where the
last timer gets canceled, so the already programmed event does not fire.
It was not necessarily meant to "fix" clockevent devices which are
pretending to be ONESHOT, but keep firing over and over.
That, said. I'm fine with the change along with a big fat comment why
this is required.
Thanks,
tglx
next prev parent reply other threads:[~2022-04-22 15:54 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 21:41 rcu_sched self-detected stall on CPU Miguel Ojeda
2022-04-06 9:31 ` Zhouyi Zhou
2022-04-06 17:00 ` Paul E. McKenney
2022-04-06 18:25 ` Zhouyi Zhou
2022-04-06 19:50 ` Paul E. McKenney
2022-04-07 2:26 ` Zhouyi Zhou
2022-04-07 10:07 ` Miguel Ojeda
2022-04-07 15:15 ` Paul E. McKenney
2022-04-07 17:05 ` Miguel Ojeda
2022-04-07 17:55 ` Paul E. McKenney
2022-04-07 23:14 ` Zhouyi Zhou
2022-04-08 1:43 ` Paul E. McKenney
2022-04-08 7:23 ` Michael Ellerman
2022-04-08 10:02 ` Zhouyi Zhou
2022-04-08 14:07 ` Paul E. McKenney
2022-04-08 14:25 ` Zhouyi Zhou
2022-04-10 11:33 ` Michael Ellerman
2022-04-11 3:05 ` Paul E. McKenney
2022-04-12 6:53 ` Michael Ellerman
2022-04-12 13:36 ` Paul E. McKenney
2022-04-08 13:52 ` Miguel Ojeda
2022-04-08 14:06 ` Paul E. McKenney
2022-04-08 14:42 ` Michael Ellerman
2022-04-08 15:52 ` Paul E. McKenney
2022-04-08 17:02 ` Miguel Ojeda
2022-04-13 5:11 ` Nicholas Piggin
2022-04-13 6:10 ` Low-res tick handler device not going to ONESHOT_STOPPED when tick is stopped (was: rcu_sched self-detected stall on CPU) Nicholas Piggin
2022-04-14 17:15 ` Paul E. McKenney
2022-04-22 15:53 ` Thomas Gleixner [this message]
2022-04-23 2:29 ` Nicholas Piggin
-- strict thread matches above, loose matches on Subject: below --
2019-08-30 19:54 [PATCH] Revert "asm-generic: Remove unneeded __ARCH_WANT_SYS_LLSEEK macro" Arnd Bergmann
[not found] ` <20190830202959.3539-1-msuchanek@suse.de>
2019-08-30 20:32 ` Arnd Bergmann
[not found] <1287422825-14999-1-git-send-email-nacc@us.ibm.com>
2010-10-18 17:26 ` [PATCH 1/7] microblaze: pci-common cleanup Nishanth Aravamudan
2010-10-20 5:31 ` Michal Simek
2010-11-01 6:29 ` Re: Michal Simek
2010-08-18 20:56 Wolfgang Denk
2010-08-19 1:04 ` Stephen Rothwell
2010-09-02 6:14 ` Re: Wolfgang Denk
2010-09-02 14:51 ` Rupjyoti Sarmah
2010-09-07 6:29 ` RE: Rupjyoti Sarmah
2009-07-23 14:38 Solomon Peachy
2009-07-26 23:38 ` Benjamin Herrenschmidt
2008-08-21 6:21 Schmid Alexander
2008-08-21 9:48 ` Wolfgang Denk
2008-01-02 18:16 Re: rsa
2007-11-01 18:18 Mead, Joseph
2007-11-01 19:07 ` Grant Likely
2007-11-02 9:35 ` MingLiu
2007-04-27 19:15 Mead, Joseph
2007-04-27 20:30 ` Scott Coulter
2007-04-12 15:44 Milton Miller
2007-04-13 2:23 ` Benjamin Herrenschmidt
2007-04-13 18:45 ` Re: Segher Boessenkool
2007-04-13 18:59 ` Re: Sergei Shtylyov
2007-04-13 19:10 ` Re: Segher Boessenkool
1999-05-18 7:26 nicolas.boussekeyt
1999-05-18 18:03 ` Alex Vallens
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=87fsm55d3f.ffs@tglx \
--to=tglx@linutronix.de \
--cc=daniel.lezcano@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=zhouzhouyi@gmail.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 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).