Re: Time keeping while suspended in the presence of persistent clock drift

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 15/12/2021 13:06:30-0800, John Stultz wrote:
> I'm not really active in this space much anymore, but a few of my
> (possibly wrongheaded) thoughts:
> 
> >    [A] On machines with a persistent clock how is userspace supposed
> >        to be sure what drift to measure? Can it assume that the drift
> >        of the persistent clock used for sleep time injection is the
> >        same as the drift of /dev/rtc? This seems dangerous.
> 
> Yea, there can be multiple RTCs as well.
> 
> >    [B] Sleep time injection can come from the "persistent clock" or,
> >        if there is no persistent clock, from an RTC driver. I'd like
> >        to correct for drift from the perisistant clock but not touch
> >        the RTC driver sleep time injection mechanism. Is this
> >        acceptable or do people feel that any drift correction should
> >        work with both mechanisms in order to ensure a polished
> >        interface?
> 
> This dual interface comes from the desire to support both the more
> atomic/earlier correction we can do w/ the persistent_clock interface
> while holding the timekeeping lock, while also supporting RTC devices
> that may sleep when being read, or may have dependencies that aren't
> ready that early in resume.
> 
> Admittedly having two separate abstractions here is a bit of a pain,
> and fixing just one side doesn't make it better.
> 
> >    [C] Some users may want to correct for drift during suspend-to-RAM
> >        but during suspend-to-disk they might boot into some other
> >        operating system which itself sets the CMOS RTC. Hopefully,
> >        this could be solved from userspace by changing the drift
> >        correction parameter to 0 just before a suspend-to-disk
> >        operation.
> 
> Oof. This feels particularly complex and fragile to try to address.
> 
> > I suspect that there are other things about which I should also be
> > worried if only I were less ignorant. That is why I am asking here.
> 
> Personally, I'm not sure this warrants adding new userland interfaces
> for. I'd probably lean towards having the RTC framework internally
> measure and correct for drift, rather than adding an extra knob in
> userland.
> 

I'd rather lean towards the timekeeping code doing that. The RTC
subsystem doesn't know which RTC has to be used.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com