Messages in this thread | | | Date | Thu, 16 Nov 2017 01:37:41 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [GIT pull] printk updates for 4.15 |
| |
On Wed, 15 Nov 2017, Linus Torvalds wrote: > > So I agree with all of this, but I wonder what actuall yuses that > BOOTTIME to make it worth even synchronizing with. > > I'm assuming it's some evdev user. > > But I'm wondering if perhaps we could just simplify our own lives and > make CLOCK_BOOTTIME and CLOCK_MONOTONIC just be the same. > > And we'd make them be the same by making CLOCK_MONOTONIC act like > CLOCK_BOOTTIME. > > I doubt anybody would notice. > > At least we could _try_ that kind of system clock simplification. > Maybe people would scream bloody murder and we'd have to revert, but > wouldn't it be lovely to simplify the synchronization problem by just > making it go away (well, at least for the BOOTTIME/MONOTONIC case).
Yes it would be lovely. I have some vague memories about having MONOTONIC behave the same way as BOOTTIME in the early days of the generic timekeeping infrastructure, high resolution timers and idle NOHZ work, 10+ years ago.
This broke stuff because the historic behaviour was to not advance on resume and the change caused massive timer expiries right after resume which confused the hell out of things, because timers fired immediately which were not expected to fire as they were implicitely relying on suspend not affecting clock monotonic.
So we reverted back to the old behaviour.
Soon after that, people complained about not being able to arm timers which should expire after a resume or get access to the time spent there, but they could not use REALTIME due to time jumps caused by DST and whatever. So we introduced BOOTTIME.
In hindsight it might have been better not to do that, but now we have to deal with it.
I'm a bit worried to change that because the behaviour difference of MONOTONIC and BOOTTIME vs. suspend/resume is well documented all over the place and there are explicit choices made in applications and libraries which one of them to use for a particular problem. So I expect that some of the surprises we've seen 10+ years ago still persist.
I'm also quite sure that there is kernel code which relies implicitely on that behaviour. We surely can fix that, but it might be tedious to debug.
John?
Thanks,
tglx
| |