Messages in this thread | | | From | John Stultz <> | Date | Wed, 15 Nov 2017 17:23:00 -0800 | Subject | Re: [GIT pull] printk updates for 4.15 |
| |
On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > 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?
Yea, I don't think we could get away with replacing CLOCK_MONOTONIC with CLOCK_BOOTTIME at this point. I think in retrospect, for userspace it probably would have been the right decision when we were initially sorting how CLOCK_MONOTONIC hrtimers and suspend would work together, but even then, we would still need something like the current CLOCK_MONOTONIC internally for the kernel to avoid spinning firing a million recurring timers on resume after a long suspend. Then having a non 1:1 mapping from the kernel's internal sense of MONOTONIC and userland's sense would have add more complexity.
Even if years ago we had defined CLOCK_MONOTONIC to work like CLOCK_BOOTTIME for userspace, I suspect we'd end up having apps wanting something like CLOCK_RUNTIME to get similar non-suspend accounting behavior. :)
thanks -john
| |