Message-ID: <CALAqxLW1JBLmgQ4J9=3Efp++58RiY=_C-q=+fMgYWfk2wq0eSw@mail.gmail.com>
Date:   Wed, 15 Nov 2017 17:23:00 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Petr Mladek <pmladek@...e.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [GIT pull] printk updates for 4.15

On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner <tglx@...utronix.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

Powered by blists - more mailing lists