All of lore.kernel.org
 help / color / mirror / Atom feed
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


             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.