Re: [GIT pull] printk updates for 4.15

[Thomas Gleixner <tglx@linutronix.de>]

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