Re: [GIT pull] printk updates for 4.15

From: John Stultz <john.stultz@linaro.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Mark Salyzyn <salyzyn@android.com>,
	Petr Mladek <pmladek@suse.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [GIT pull] printk updates for 4.15
Date: Wed, 15 Nov 2017 17:23:00 -0800	[thread overview]
Message-ID: <CALAqxLW1JBLmgQ4J9=3Efp++58RiY=_C-q=+fMgYWfk2wq0eSw@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1711160011300.2146@nanos>

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