[PATCH] timers: Stop hrtimer queue traversal after seq_file overflow

[PATCH] timers: Stop hrtimer queue traversal after seq_file overflow

[Avi Weiss]

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@gmail.com>
---
 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;
 	i = 0;
 
 	touch_nmi_watchdog();
-- 
2.43.0

Re: [PATCH] timers: Stop hrtimer queue traversal after seq_file overflow

[Frederic Weisbecker]

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@gmail.com>
> ---
>  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

Re: [PATCH] timers: Stop hrtimer queue traversal after seq_file overflow

[Avi]

Yes exactly - harmless, but unnecessary and wasteful.

On Tue, Nov 3, 2026 at 3:34 PM Frederic Weisbecker <frederic@kernel.org> 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@gmail.com>
> > ---
> >  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