From: <markus.stockhausen@gmx.de>
To: <peterz@infradead.org>
Cc: "'Chris Packham'" <Chris.Packham@alliedtelesis.co.nz>,
<bjorn@mork.no>, <mingo@redhat.com>, <juri.lelli@redhat.com>,
<vincent.guittot@linaro.org>, <anna-maria@linutronix.de>,
<frederic@kernel.org>, <tglx@linutronix.de>,
<linux-kernel@vger.kernel.org>
Subject: task_non_contending() for fair_server leads to timer retries
Date: Tue, 15 Jul 2025 16:39:25 +0200 [thread overview]
Message-ID: <085d01dbf596$44286880$cc793980$@gmx.de> (raw)
Hi Peter,
I'm currently investigating issues with the timer-rtl-otto driver in
6.12 longterm on the Realtek MIPS switch platform (Chris is working
hard to upstream this). While doing so I observed that timer retries
continually increase (~6/second) according to /proc/timer_list. The
system is otherwise totally idle. 6.6 longterm does not show that issue.
I'm unsure if this is related but documentation reads like "that's bad".
To be sure about this one I nailed it down to the fair server.
Whenever task_non_contending() handles the fair_server, zerolag_time is
calculated as 0 and a hrtimer_start(timer, 0, ...) call is issued. Going
down the stack clockevents_program_event() thinks the target time has
been exceeded. So it instructs clockevents_program_min_delta() to set
a minimum delta time (2560ns for the otto timer). From there the retry
counter is increased. See attached output.
To silence the noise and focus on the real bug I use this workaround
in task_non_contending():
if ((dl_se == &rq->fair_server) && (zerolag_time == 0))
zerolag_time = 6000;
Totally crap but serves the purpose. Maybe you can share insights about
this (un)desired behaviour.
Thanks in advance.
Markus
# uptime
00:41:19 up 41 min, load average: 0.00, 0.00, 0.00
# cat /proc/timer_list
...
Tick Device: mode: 1
Per CPU device: 0
Clock Event Device: timer@3100
max_delta_ns: 85899344321
min_delta_ns: 2560
mult: 13421773
shift: 32
mode: 3
next_event: 2469910000000 nsecs
set_next_event: rttm_next_event
shutdown: rttm_state_shutdown
periodic: rttm_state_periodic
oneshot: rttm_state_oneshot
event_handler: hrtimer_interrupt
retries: 14646
next reply other threads:[~2025-07-15 14:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-15 14:39 markus.stockhausen [this message]
2025-07-17 9:05 ` task_non_contending() for fair_server leads to timer retries Juri Lelli
2025-07-17 15:05 ` Bjørn Mork
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='085d01dbf596$44286880$cc793980$@gmx.de' \
--to=markus.stockhausen@gmx.de \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=anna-maria@linutronix.de \
--cc=bjorn@mork.no \
--cc=frederic@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=vincent.guittot@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.