Re: [RFCv4] timerfd: add TFD_NOTIFY_CLOCK_SET to watch for clock changes

On Thu, 10 Mar 2011, Jamie Lokier wrote:

Thomas Gleixner wrote:

quoted

Note, that we have CLOCK_BOOTTIME pending for .39 which aims at the
same problem. It's basically CLOCK_MONOTONIC adjusted by the time we
were in suspend. So while CLOCK_MONOTONIC timers are not aware of the
time spent in suspend CLOCK_BOOTTIME timers are. The reason for
implementing CLOCK_BOOTTIME was basically the same problem.

I'm afraid for coherent distributed system problems,
I don't trust CLOCK_BOOTTIME.

That timerfd thing as proposed will not solve that either.

What happens when the clock battery is flat?  (Some systems have
separate battery for the clock, and it's never changed or recharged).

Then your timekeeping is hosed anyway, so that's the least of your
worries.

What about systems that just don't have a hardware clock while
suspended, or the clock doesn't remember the current year reliably, or
it's handled by userspace not the kernel?

(I have a system here where the clock battery will eventually run
down, and which has a userspace-only hwclock driver)

Ditto. And I really do not care about user space only drivers at all.
 

What happens if user does suspend to disk and resumes the disk image
after they used a different OS for a while, which has meanwhile also
altered the clock?

Again, your timekeeping is busted.

Or suspend to disk on a VM followed by moving to a different VM host.

If your hosts have a complete different notion of clock realtime or
provide complete different based RTC emulation, then you run into a
whole set of other problems.

In general I trust CLOCK_BOOTTIME to be a reasonable measure of
elapsed time most of the time - but not reliable enough for
distributed systems (such as coherent caches) that need stricter
guarantees whatever the client hardware, or need to know when those
guarantees aren't met.

Whereas I'd trust an "something happened so recalibate" event that is
always triggered - provided it's not sent too early or too late
relative to clock measurements and timer queue reads.  I've yet to
check if these proposed timerfd events meet that criterion.

Not at all. There is no guarantee, that the process waiting for that
timerfd notification will resume before any other process which might
be affected by such an event.

You try to square the circle, but that won't happen before pigs fly.

Thanks,

	tglx