On Thu, 10 Mar 2011, Jamie Lokier wrote: > Thomas Gleixner wrote: > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
