[lkml]   [2021]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Time keeping while suspended in the presence of persistent clock drift
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

 \ /
  Last update: 2021-12-15 22:33    [W:0.180 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site