Re: [PATCH] timers: Stop hrtimer queue traversal after seq_file overflow
From: Avi
Date: Tue Nov 03 2026 - 09:14:33 EST
Yes exactly - harmless, but unnecessary and wasteful.
On Tue, Nov 3, 2026 at 3:34 PM Frederic Weisbecker <frederic@xxxxxxxxxx> wrote:
>
> Le Tue, Nov 03, 2026 at 12:34:39PM +0200, Avi Weiss a écrit :
> > When /proc/timer_list overflows its seq_file buffer, seq_file retries
> > formatting with a larger buffer. print_active_timers() nevertheless
> > continues scanning the remaining hrtimers, restarting its quadratic
> > traversal even though the overflowing attempt will be discarded.
> >
> > Stop traversing at next_one when the seq_file has overflowed. Preserve
> > the SysRq console path, which passes a NULL seq_file pointer.
> >
> > In a (virtual) two-CPU KVM guest with 2,048 timerfds pinned to one CPU,
> > median reader CPU time for a complete /proc/timer_list read fell from
> > 51.1 ms to 14.6 ms. Repeated tests showed no material slowdown for
> > non-overflowing reads (13.7us before versus 13.8 after). Short reads,
> > seek-to-start, and SysRq-Q tests also look fine.
> >
> > Fixes: 289f480af87e ("[PATCH] Add debugging feature /proc/timer_list")
> > Signed-off-by: Avi Weiss <thnkslprpt@xxxxxxxxx>
> > ---
> > kernel/time/timer_list.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/time/timer_list.c b/kernel/time/timer_list.c
> > index 0406bf4488e9..84275b6cd2c9 100644
> > --- a/kernel/time/timer_list.c
> > +++ b/kernel/time/timer_list.c
> > @@ -64,6 +64,8 @@ static void print_active_timers(struct seq_file *m, struct hrtimer_clock_base *b
> > unsigned long flags;
> >
> > next_one:
> > + if (m && seq_has_overflowed(m))
> > + return;
>
> But it's harmless, right? I mean the bad outcome is just to spend useless cycles
> seeking and storing?
>
> Still probably makes sense though.
>
> > i = 0;
> >
> > touch_nmi_watchdog();
> > --
> > 2.43.0
> >
>
> --
> Frederic Weisbecker
> SUSE Labs