Hi all, 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! 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. 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.) 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? Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity.
signature.asc
Description: This is a digitally signed message part
