Message-ID: <CANDhNCoYPX_5m-v_sR4TJ3Xj5TVtrMLP8Bswo_-_+BMXwWUkjg@mail.gmail.com>
Date: Thu, 10 Jul 2025 14:59:56 -0700
From: John Stultz <jstultz@...gle.com>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, 
	Thomas Gleixner <tglx@...utronix.de>, LKML <linux-kernel@...r.kernel.org>, 
	linux-pm@...r.kernel.org, 1107785@...s.debian.org, 
	Tiffany Yang <ynaffit@...gle.com>
Subject: Re: User-space watchdog timers vs suspend-to-idle

On Thu, Jul 10, 2025 at 12:52 PM Ben Hutchings <ben@...adent.org.uk> wrote:
>
> There seems to be a longstanding issue with the combination of user-
> space watchdog timers (using CLOCK_MONOTONIC) and suspend-to-idle.  This
> was reported at <https://bugzilla.kernel.org/show_bug.cgi?id=200595> and
> more recently at <https://bugs.debian.org/1107785>.
>
> During suspend-to-idle the system may be woken by interrupts and the
> CLOCK_MONOTONIC clock may tick while that happens, but no user-space
> tasks are allowed to run.  So when the system finally exits suspend, a
> watchdog timer based on CLOCK_MONOTONIC may expire immediately without
> the task being supervised ever having an opportunity to pet the
> watchdog.
>
> This seems like a hard problem to solve!

So I don't know much about suspend-to-idle, but I'm surprised it's not
suspending timekeeping! That definitely seems problematic.

> By definition we cannot allow CLOCK_MONOTONIC to run backward, and I
> assume we do not want it to stop while interrupts are being handled.

How much work do we expect to be done in irq context when we are in
suspend-to-idle?
Will any IRQ that fires (I assume many are masked in suspend-to-idle)
resume the system? Or are there some irqs that fire and do work, but
return without the system resuming?

> But could CLOCK_MONOTONIC be split into a CLOCK_MONOTONIC_KERNEL (may
> tick during suspend-to-idle) and CLOCK_MONOTONIC_USER (only ticks while
> user tasks can run), with user-space CLOCK_MONOTONIC being the latter?
> (I'm aware that adding yet another clock type would be a rather large
> job even if this is possible.)

Yeah, I'm not eager for another functionally very similar clockid to
be added, though something like this approach could be used.

But I'd probably prefer to find a way to suspend/resume timekeeping
instead (likely reading the clock, calculating the delta from suspend
and calling timekeeping_inject_sleeptime64() from the irq handler).

> Until and unless that happens, is it possible to detect that
> CLOCK_MONOTONIC advanced during suspend-to-idle by reading e.g.
> /proc/schedtat?  If not, could the necessary information be exposed
> through one of the pseudo-filesystems?

This is very similar to a problem Tiffany (CC'ed) is working on:
  https://lore.kernel.org/lkml/20250603224304.3198729-3-ynaffit@google.com/

Where different tasks are frozen via the cgroup-v2 freezer, and we
want to avoid watchdog timers from firing immediately when the task is
pulled out of the freezer. In that case the proposal is to account for
the per-task or per-cgroup freezer time, and export that so the
watchdog logic understand if the application had a chance to run, or
if a new watchdog timer should just be set instead.

In that case there's a little more control over things, so adding the
freezer time into the watchdog logic is doable, but I'm not sure if a
similar approach would be viable for existing general linux
applications around CLOCK_MONOTONIC.

thanks
-john

Powered by blists - more mailing lists