Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Thu, Apr 26, 2018 at 10:51 AM, Thomas Gleixner  wrote:
> On Thu, 26 Apr 2018, Rafael J. Wysocki wrote:
>
>> On Thu, Apr 26, 2018 at 9:42 AM, Thomas Gleixner  wrote:
>> > On Thu, 26 Apr 2018, Mike Galbraith wrote:
>> >> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
>> >> > Right, it does not matter. The real interesting one is d6ed449afdb3.
>> >>
>> >> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
>> >> below after a very few minute suspend, and a short bisect fingered your
>> >> suspect.  Distro is opensuse 42.3.
>> >>
>> >> [  211.113902] Restarting tasks ... done.
>> >> [  211.114817] PM: suspend exit
>> >> [  212.312993] systemd-journald[7266]: File 
>> >> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal 
>> >> corrupted or uncleanly shut down, renaming and replacing.
>> >> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
>> >> daemon itself, diverted to 
>> >> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
>> >>
>> >
>> > Huch, that rather looks like a genuine application bug.
>>
>> Well, say you set a timer to wake you up in X seconds.  When you wake
>> up, you look at a clock and see that Y seconds have passed and Y is
>> much greater than X.  I guess you'd think that something's wrong. :-)
>
> And that makes you coredump, right? Brilliant choice.

That wouldn't be my choice, but some people do make choices like that
even in their personal lives ...

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Thu, Apr 26, 2018 at 10:51 AM, Thomas Gleixner  wrote:
> On Thu, 26 Apr 2018, Rafael J. Wysocki wrote:
>
>> On Thu, Apr 26, 2018 at 9:42 AM, Thomas Gleixner  wrote:
>> > On Thu, 26 Apr 2018, Mike Galbraith wrote:
>> >> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
>> >> > Right, it does not matter. The real interesting one is d6ed449afdb3.
>> >>
>> >> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
>> >> below after a very few minute suspend, and a short bisect fingered your
>> >> suspect.  Distro is opensuse 42.3.
>> >>
>> >> [  211.113902] Restarting tasks ... done.
>> >> [  211.114817] PM: suspend exit
>> >> [  212.312993] systemd-journald[7266]: File 
>> >> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal 
>> >> corrupted or uncleanly shut down, renaming and replacing.
>> >> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
>> >> daemon itself, diverted to 
>> >> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
>> >>
>> >
>> > Huch, that rather looks like a genuine application bug.
>>
>> Well, say you set a timer to wake you up in X seconds.  When you wake
>> up, you look at a clock and see that Y seconds have passed and Y is
>> much greater than X.  I guess you'd think that something's wrong. :-)
>
> And that makes you coredump, right? Brilliant choice.

That wouldn't be my choice, but some people do make choices like that
even in their personal lives ...

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 26 Apr 2018, Rafael J. Wysocki wrote:

> On Thu, Apr 26, 2018 at 9:42 AM, Thomas Gleixner  wrote:
> > On Thu, 26 Apr 2018, Mike Galbraith wrote:
> >> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
> >> > Right, it does not matter. The real interesting one is d6ed449afdb3.
> >>
> >> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
> >> below after a very few minute suspend, and a short bisect fingered your
> >> suspect.  Distro is opensuse 42.3.
> >>
> >> [  211.113902] Restarting tasks ... done.
> >> [  211.114817] PM: suspend exit
> >> [  212.312993] systemd-journald[7266]: File 
> >> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted 
> >> or uncleanly shut down, renaming and replacing.
> >> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
> >> daemon itself, diverted to 
> >> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
> >>
> >
> > Huch, that rather looks like a genuine application bug.
> 
> Well, say you set a timer to wake you up in X seconds.  When you wake
> up, you look at a clock and see that Y seconds have passed and Y is
> much greater than X.  I guess you'd think that something's wrong. :-)

And that makes you coredump, right? Brilliant choice.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 26 Apr 2018, Rafael J. Wysocki wrote:

> On Thu, Apr 26, 2018 at 9:42 AM, Thomas Gleixner  wrote:
> > On Thu, 26 Apr 2018, Mike Galbraith wrote:
> >> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
> >> > Right, it does not matter. The real interesting one is d6ed449afdb3.
> >>
> >> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
> >> below after a very few minute suspend, and a short bisect fingered your
> >> suspect.  Distro is opensuse 42.3.
> >>
> >> [  211.113902] Restarting tasks ... done.
> >> [  211.114817] PM: suspend exit
> >> [  212.312993] systemd-journald[7266]: File 
> >> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted 
> >> or uncleanly shut down, renaming and replacing.
> >> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
> >> daemon itself, diverted to 
> >> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
> >>
> >
> > Huch, that rather looks like a genuine application bug.
> 
> Well, say you set a timer to wake you up in X seconds.  When you wake
> up, you look at a clock and see that Y seconds have passed and Y is
> much greater than X.  I guess you'd think that something's wrong. :-)

And that makes you coredump, right? Brilliant choice.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Thu, Apr 26, 2018 at 9:42 AM, Thomas Gleixner  wrote:
> On Thu, 26 Apr 2018, Mike Galbraith wrote:
>> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
>> > Right, it does not matter. The real interesting one is d6ed449afdb3.
>>
>> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
>> below after a very few minute suspend, and a short bisect fingered your
>> suspect.  Distro is opensuse 42.3.
>>
>> [  211.113902] Restarting tasks ... done.
>> [  211.114817] PM: suspend exit
>> [  212.312993] systemd-journald[7266]: File 
>> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted 
>> or uncleanly shut down, renaming and replacing.
>> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
>> daemon itself, diverted to 
>> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
>>
>
> Huch, that rather looks like a genuine application bug.

Well, say you set a timer to wake you up in X seconds.  When you wake
up, you look at a clock and see that Y seconds have passed and Y is
much greater than X.  I guess you'd think that something's wrong. :-)

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Thu, Apr 26, 2018 at 9:42 AM, Thomas Gleixner  wrote:
> On Thu, 26 Apr 2018, Mike Galbraith wrote:
>> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
>> > Right, it does not matter. The real interesting one is d6ed449afdb3.
>>
>> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
>> below after a very few minute suspend, and a short bisect fingered your
>> suspect.  Distro is opensuse 42.3.
>>
>> [  211.113902] Restarting tasks ... done.
>> [  211.114817] PM: suspend exit
>> [  212.312993] systemd-journald[7266]: File 
>> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted 
>> or uncleanly shut down, renaming and replacing.
>> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
>> daemon itself, diverted to 
>> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
>>
>
> Huch, that rather looks like a genuine application bug.

Well, say you set a timer to wake you up in X seconds.  When you wake
up, you look at a clock and see that Y seconds have passed and Y is
much greater than X.  I guess you'd think that something's wrong. :-)

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 26 Apr 2018, Mike Galbraith wrote:
> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
> > Right, it does not matter. The real interesting one is d6ed449afdb3.
> 
> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
> below after a very few minute suspend, and a short bisect fingered your
> suspect.  Distro is opensuse 42.3.
> 
> [  211.113902] Restarting tasks ... done.
> [  211.114817] PM: suspend exit
> [  212.312993] systemd-journald[7266]: File 
> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted or 
> uncleanly shut down, renaming and replacing.
> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
> daemon itself, diverted to 
> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
> 

Huch, that rather looks like a genuine application bug.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 26 Apr 2018, Mike Galbraith wrote:
> On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
> > Right, it does not matter. The real interesting one is d6ed449afdb3.
> 
> FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
> below after a very few minute suspend, and a short bisect fingered your
> suspect.  Distro is opensuse 42.3.
> 
> [  211.113902] Restarting tasks ... done.
> [  211.114817] PM: suspend exit
> [  212.312993] systemd-journald[7266]: File 
> /var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted or 
> uncleanly shut down, renaming and replacing.
> [  212.313363] systemd-coredump[7264]: Detected coredump of the journal 
> daemon itself, diverted to 
> /var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.
> 

Huch, that rather looks like a genuine application bug.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Mike Galbraith]

On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
> Right, it does not matter. The real interesting one is d6ed449afdb3.

FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
below after a very few minute suspend, and a short bisect fingered your
suspect.  Distro is opensuse 42.3.

[  211.113902] Restarting tasks ... done.
[  211.114817] PM: suspend exit
[  212.312993] systemd-journald[7266]: File 
/var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted or 
uncleanly shut down, renaming and replacing.
[  212.313363] systemd-coredump[7264]: Detected coredump of the journal daemon 
itself, diverted to 
/var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Mike Galbraith]

On Wed, 2018-04-25 at 15:03 +0200, Thomas Gleixner wrote:
> Right, it does not matter. The real interesting one is d6ed449afdb3.

FWIW, three boxen here suspend/resume fine, but repeatably exhibit the
below after a very few minute suspend, and a short bisect fingered your
suspect.  Distro is opensuse 42.3.

[  211.113902] Restarting tasks ... done.
[  211.114817] PM: suspend exit
[  212.312993] systemd-journald[7266]: File 
/var/log/journal/016627c3c4784cd4812d4b7e96a34226/system.journal corrupted or 
uncleanly shut down, renaming and replacing.
[  212.313363] systemd-coredump[7264]: Detected coredump of the journal daemon 
itself, diverted to 
/var/lib/systemd/coredump/core.systemd-journal.0.0aa39276decf4f1ab6fda3464e31f9dd.582.152472095400.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Wed, 25 Apr 2018, Rafael J. Wysocki wrote:
> On Wednesday, April 25, 2018 10:52:18 AM CEST Rafael J. Wysocki wrote:
> > On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> > > On Mon, 23 Apr 2018, John Stultz wrote:
> > > 
> > > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > > > >> I came across this thread for same reason as [0]: Daemons getting
> > > > >> killed by systemd on resume (after >WatchdogSec seconds of
> > > > >> suspending). I'm using master branch of systemd and the kernel. As
> > > > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > > > >> not include suspend time.
> > > > >>
> > > > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > > > >> this patch series breaks systemd. If it's implemented correctly, 
> > > > >> you'd
> > > > >> hope it *would* break it!
> > > > >
> > > > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > > > any daemon getting killed).
> > > > >
> > > > > Let me know if I can help in any way.
> > > > 
> > > > Yea, this is the sort of thing I was worried about.
> > > > 
> > > > Thomas: I think reverting this change is needed.
> > > 
> > > Sigh. I hoped that something like this would be catched before I sent the
> > > pull request by those who were actually interested in this change...
> > 
> > The "git revert -m 1 680014d6d1da" makes resume issues on my Aspire S5
> > go away (cf. https://marc.info/?l=linux-kernel=152460804018920=2).
> > 
> > I'll try with just the "monotonic" vs "boottime" clock changes reverted.
> 
> FWICS (so far) system resume still works here with the commits between
> d6ed449afdb3 (timekeeping: Make the MONOTONIC clock behave like the BOOTTIME
> clock) and 127bfa5f4342 (hrtimer: Unify MONOTONIC and BOOTTIME clock behavior)
> inclusive reverted on top of 4.17-rc2.  [I probably should revert commit
> 92af4dcb4e1c (tracing: Unify the "boot" and "mono" tracing clocks) too, but
> it doesn't revert cleanly and it doesn't apprear to affect things here too.]

Right, it does not matter. The real interesting one is d6ed449afdb3.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Wed, 25 Apr 2018, Rafael J. Wysocki wrote:
> On Wednesday, April 25, 2018 10:52:18 AM CEST Rafael J. Wysocki wrote:
> > On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> > > On Mon, 23 Apr 2018, John Stultz wrote:
> > > 
> > > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > > > >> I came across this thread for same reason as [0]: Daemons getting
> > > > >> killed by systemd on resume (after >WatchdogSec seconds of
> > > > >> suspending). I'm using master branch of systemd and the kernel. As
> > > > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > > > >> not include suspend time.
> > > > >>
> > > > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > > > >> this patch series breaks systemd. If it's implemented correctly, 
> > > > >> you'd
> > > > >> hope it *would* break it!
> > > > >
> > > > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > > > any daemon getting killed).
> > > > >
> > > > > Let me know if I can help in any way.
> > > > 
> > > > Yea, this is the sort of thing I was worried about.
> > > > 
> > > > Thomas: I think reverting this change is needed.
> > > 
> > > Sigh. I hoped that something like this would be catched before I sent the
> > > pull request by those who were actually interested in this change...
> > 
> > The "git revert -m 1 680014d6d1da" makes resume issues on my Aspire S5
> > go away (cf. https://marc.info/?l=linux-kernel=152460804018920=2).
> > 
> > I'll try with just the "monotonic" vs "boottime" clock changes reverted.
> 
> FWICS (so far) system resume still works here with the commits between
> d6ed449afdb3 (timekeeping: Make the MONOTONIC clock behave like the BOOTTIME
> clock) and 127bfa5f4342 (hrtimer: Unify MONOTONIC and BOOTTIME clock behavior)
> inclusive reverted on top of 4.17-rc2.  [I probably should revert commit
> 92af4dcb4e1c (tracing: Unify the "boot" and "mono" tracing clocks) too, but
> it doesn't revert cleanly and it doesn't apprear to affect things here too.]

Right, it does not matter. The real interesting one is d6ed449afdb3.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 10:52:18 AM CEST Rafael J. Wysocki wrote:
> On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> > On Mon, 23 Apr 2018, John Stultz wrote:
> > 
> > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > > >> I came across this thread for same reason as [0]: Daemons getting
> > > >> killed by systemd on resume (after >WatchdogSec seconds of
> > > >> suspending). I'm using master branch of systemd and the kernel. As
> > > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > > >> not include suspend time.
> > > >>
> > > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > > >> this patch series breaks systemd. If it's implemented correctly, you'd
> > > >> hope it *would* break it!
> > > >
> > > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > > any daemon getting killed).
> > > >
> > > > Let me know if I can help in any way.
> > > 
> > > Yea, this is the sort of thing I was worried about.
> > > 
> > > Thomas: I think reverting this change is needed.
> > 
> > Sigh. I hoped that something like this would be catched before I sent the
> > pull request by those who were actually interested in this change...
> 
> The "git revert -m 1 680014d6d1da" makes resume issues on my Aspire S5
> go away (cf. https://marc.info/?l=linux-kernel=152460804018920=2).
> 
> I'll try with just the "monotonic" vs "boottime" clock changes reverted.

FWICS (so far) system resume still works here with the commits between
d6ed449afdb3 (timekeeping: Make the MONOTONIC clock behave like the BOOTTIME
clock) and 127bfa5f4342 (hrtimer: Unify MONOTONIC and BOOTTIME clock behavior)
inclusive reverted on top of 4.17-rc2.  [I probably should revert commit
92af4dcb4e1c (tracing: Unify the "boot" and "mono" tracing clocks) too, but
it doesn't revert cleanly and it doesn't apprear to affect things here too.]

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 10:52:18 AM CEST Rafael J. Wysocki wrote:
> On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> > On Mon, 23 Apr 2018, John Stultz wrote:
> > 
> > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > > >> I came across this thread for same reason as [0]: Daemons getting
> > > >> killed by systemd on resume (after >WatchdogSec seconds of
> > > >> suspending). I'm using master branch of systemd and the kernel. As
> > > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > > >> not include suspend time.
> > > >>
> > > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > > >> this patch series breaks systemd. If it's implemented correctly, you'd
> > > >> hope it *would* break it!
> > > >
> > > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > > any daemon getting killed).
> > > >
> > > > Let me know if I can help in any way.
> > > 
> > > Yea, this is the sort of thing I was worried about.
> > > 
> > > Thomas: I think reverting this change is needed.
> > 
> > Sigh. I hoped that something like this would be catched before I sent the
> > pull request by those who were actually interested in this change...
> 
> The "git revert -m 1 680014d6d1da" makes resume issues on my Aspire S5
> go away (cf. https://marc.info/?l=linux-kernel=152460804018920=2).
> 
> I'll try with just the "monotonic" vs "boottime" clock changes reverted.

FWICS (so far) system resume still works here with the commits between
d6ed449afdb3 (timekeeping: Make the MONOTONIC clock behave like the BOOTTIME
clock) and 127bfa5f4342 (hrtimer: Unify MONOTONIC and BOOTTIME clock behavior)
inclusive reverted on top of 4.17-rc2.  [I probably should revert commit
92af4dcb4e1c (tracing: Unify the "boot" and "mono" tracing clocks) too, but
it doesn't revert cleanly and it doesn't apprear to affect things here too.]

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 8:50:15 AM CEST Pavel Machek wrote:
> 
> --ReaqsoxgOBHFXBhH
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue 2018-04-24 10:09:28, Thomas Gleixner wrote:
> > On Mon, 23 Apr 2018, John Stultz wrote:
> >=20
> > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > > >> I came across this thread for same reason as [0]: Daemons getting
> > > >> killed by systemd on resume (after >WatchdogSec seconds of
> > > >> suspending). I'm using master branch of systemd and the kernel. As
> > > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > > >> not include suspend time.
> > > >>
> > > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > > >> this patch series breaks systemd. If it's implemented correctly, you=
> 'd
> > > >> hope it *would* break it!
> > > >
> > > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > > any daemon getting killed).
> > > >
> > > > Let me know if I can help in any way.
> > >=20
> > > Yea, this is the sort of thing I was worried about.
> > >=20
> > > Thomas: I think reverting this change is needed.
> >=20
> > Sigh. I hoped that something like this would be catched before I sent the
> > pull request by those who were actually interested in this change...
> 
> Well, we had two regressions in -next this cycle... I reported both
> but bisections were not easy and noone was really interested.

It's more that it was difficult to correlate the reported symptoms with a
particular set of kernel changes.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 8:50:15 AM CEST Pavel Machek wrote:
> 
> --ReaqsoxgOBHFXBhH
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Tue 2018-04-24 10:09:28, Thomas Gleixner wrote:
> > On Mon, 23 Apr 2018, John Stultz wrote:
> >=20
> > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > > >> I came across this thread for same reason as [0]: Daemons getting
> > > >> killed by systemd on resume (after >WatchdogSec seconds of
> > > >> suspending). I'm using master branch of systemd and the kernel. As
> > > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > > >> not include suspend time.
> > > >>
> > > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > > >> this patch series breaks systemd. If it's implemented correctly, you=
> 'd
> > > >> hope it *would* break it!
> > > >
> > > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > > any daemon getting killed).
> > > >
> > > > Let me know if I can help in any way.
> > >=20
> > > Yea, this is the sort of thing I was worried about.
> > >=20
> > > Thomas: I think reverting this change is needed.
> >=20
> > Sigh. I hoped that something like this would be catched before I sent the
> > pull request by those who were actually interested in this change...
> 
> Well, we had two regressions in -next this cycle... I reported both
> but bisections were not easy and noone was really interested.

It's more that it was difficult to correlate the reported symptoms with a
particular set of kernel changes.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> On Mon, 23 Apr 2018, John Stultz wrote:
> 
> > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > >> I came across this thread for same reason as [0]: Daemons getting
> > >> killed by systemd on resume (after >WatchdogSec seconds of
> > >> suspending). I'm using master branch of systemd and the kernel. As
> > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > >> not include suspend time.
> > >>
> > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > >> this patch series breaks systemd. If it's implemented correctly, you'd
> > >> hope it *would* break it!
> > >
> > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > any daemon getting killed).
> > >
> > > Let me know if I can help in any way.
> > 
> > Yea, this is the sort of thing I was worried about.
> > 
> > Thomas: I think reverting this change is needed.
> 
> Sigh. I hoped that something like this would be catched before I sent the
> pull request by those who were actually interested in this change...

The "git revert -m 1 680014d6d1da" makes resume issues on my Aspire S5
go away (cf. https://marc.info/?l=linux-kernel=152460804018920=2).

I'll try with just the "monotonic" vs "boottime" clock changes reverted.

> I'll try to distangle it.

Cool.

Please let me know if you need any help.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Rafael J. Wysocki]

On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> On Mon, 23 Apr 2018, John Stultz wrote:
> 
> > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > >> I came across this thread for same reason as [0]: Daemons getting
> > >> killed by systemd on resume (after >WatchdogSec seconds of
> > >> suspending). I'm using master branch of systemd and the kernel. As
> > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > >> not include suspend time.
> > >>
> > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > >> this patch series breaks systemd. If it's implemented correctly, you'd
> > >> hope it *would* break it!
> > >
> > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > any daemon getting killed).
> > >
> > > Let me know if I can help in any way.
> > 
> > Yea, this is the sort of thing I was worried about.
> > 
> > Thomas: I think reverting this change is needed.
> 
> Sigh. I hoped that something like this would be catched before I sent the
> pull request by those who were actually interested in this change...

The "git revert -m 1 680014d6d1da" makes resume issues on my Aspire S5
go away (cf. https://marc.info/?l=linux-kernel=152460804018920=2).

I'll try with just the "monotonic" vs "boottime" clock changes reverted.

> I'll try to distangle it.

Cool.

Please let me know if you need any help.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Pavel Machek]

On Tue 2018-04-24 10:09:28, Thomas Gleixner wrote:
> On Mon, 23 Apr 2018, John Stultz wrote:
> 
> > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > >> I came across this thread for same reason as [0]: Daemons getting
> > >> killed by systemd on resume (after >WatchdogSec seconds of
> > >> suspending). I'm using master branch of systemd and the kernel. As
> > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > >> not include suspend time.
> > >>
> > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > >> this patch series breaks systemd. If it's implemented correctly, you'd
> > >> hope it *would* break it!
> > >
> > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > any daemon getting killed).
> > >
> > > Let me know if I can help in any way.
> > 
> > Yea, this is the sort of thing I was worried about.
> > 
> > Thomas: I think reverting this change is needed.
> 
> Sigh. I hoped that something like this would be catched before I sent the
> pull request by those who were actually interested in this change...

Well, we had two regressions in -next this cycle... I reported both
but bisections were not easy and noone was really interested.

See

Re: linux-next on x60: network manager often complains "network is
disabled" after resume

Subject: Re: CLOCK_MONOTONIC, BOOTTIME, suspend and screensaver
regression

Can we expect this to be sorted out in v4.17-rc3? -next?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Pavel Machek]

On Tue 2018-04-24 10:09:28, Thomas Gleixner wrote:
> On Mon, 23 Apr 2018, John Stultz wrote:
> 
> > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> > >> I came across this thread for same reason as [0]: Daemons getting
> > >> killed by systemd on resume (after >WatchdogSec seconds of
> > >> suspending). I'm using master branch of systemd and the kernel. As
> > >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> > >> not include suspend time.
> > >>
> > >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> > >> this patch series breaks systemd. If it's implemented correctly, you'd
> > >> hope it *would* break it!
> > >
> > > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > > any daemon getting killed).
> > >
> > > Let me know if I can help in any way.
> > 
> > Yea, this is the sort of thing I was worried about.
> > 
> > Thomas: I think reverting this change is needed.
> 
> Sigh. I hoped that something like this would be catched before I sent the
> pull request by those who were actually interested in this change...

Well, we had two regressions in -next this cycle... I reported both
but bisections were not easy and noone was really interested.

See

Re: linux-next on x60: network manager often complains "network is
disabled" after resume

Subject: Re: CLOCK_MONOTONIC, BOOTTIME, suspend and screensaver
regression

Can we expect this to be sorted out in v4.17-rc3? -next?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Tue, 24 Apr 2018, Genki Sky wrote:
> Sorry to have been the bearer of bad news :(.

No problem. We're not shooting the messengers

> Again, I just have my user hat on here. It does seem like this unifying
> would have been nice to have. And even, more compliant with the POSIX
> definition of MONOTONIC...

Yes, that was the idea

> On that note, maybe it is still worth introducing MONOTONIC_ACTIVE,
> but just as an alias for MONOTONIC for now. It's also more
> self-documenting. Then sometime in the future, if people switch over,
> remove BOOTTIME and make MONOTONIC like BOOTTIME. Though this doesn't
> help simplify the code, I know.

It doesn't and it does not make applications magically make use of
MONOTONIC_ACTIVE. We're in a trap here.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Tue, 24 Apr 2018, Genki Sky wrote:
> Sorry to have been the bearer of bad news :(.

No problem. We're not shooting the messengers

> Again, I just have my user hat on here. It does seem like this unifying
> would have been nice to have. And even, more compliant with the POSIX
> definition of MONOTONIC...

Yes, that was the idea

> On that note, maybe it is still worth introducing MONOTONIC_ACTIVE,
> but just as an alias for MONOTONIC for now. It's also more
> self-documenting. Then sometime in the future, if people switch over,
> remove BOOTTIME and make MONOTONIC like BOOTTIME. Though this doesn't
> help simplify the code, I know.

It doesn't and it does not make applications magically make use of
MONOTONIC_ACTIVE. We're in a trap here.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Genki Sky]

Sorry to have been the bearer of bad news :(. Again, I just have my
user hat on here. It does seem like this unifying would have been nice
to have. And even, more compliant with the POSIX definition of
MONOTONIC...

On that note, maybe it is still worth introducing MONOTONIC_ACTIVE,
but just as an alias for MONOTONIC for now. It's also more
self-documenting. Then sometime in the future, if people switch over,
remove BOOTTIME and make MONOTONIC like BOOTTIME. Though this doesn't
help simplify the code, I know.

  Thanks again,
  Genki

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Genki Sky]

Sorry to have been the bearer of bad news :(. Again, I just have my
user hat on here. It does seem like this unifying would have been nice
to have. And even, more compliant with the POSIX definition of
MONOTONIC...

On that note, maybe it is still worth introducing MONOTONIC_ACTIVE,
but just as an alias for MONOTONIC for now. It's also more
self-documenting. Then sometime in the future, if people switch over,
remove BOOTTIME and make MONOTONIC like BOOTTIME. Though this doesn't
help simplify the code, I know.

  Thanks again,
  Genki

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Mon, 23 Apr 2018, John Stultz wrote:

> On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> >> I came across this thread for same reason as [0]: Daemons getting
> >> killed by systemd on resume (after >WatchdogSec seconds of
> >> suspending). I'm using master branch of systemd and the kernel. As
> >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> >> not include suspend time.
> >>
> >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> >> this patch series breaks systemd. If it's implemented correctly, you'd
> >> hope it *would* break it!
> >
> > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > any daemon getting killed).
> >
> > Let me know if I can help in any way.
> 
> Yea, this is the sort of thing I was worried about.
> 
> Thomas: I think reverting this change is needed.

Sigh. I hoped that something like this would be catched before I sent the
pull request by those who were actually interested in this change...

I'll try to distangle it.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Mon, 23 Apr 2018, John Stultz wrote:

> On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> > Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> >> I came across this thread for same reason as [0]: Daemons getting
> >> killed by systemd on resume (after >WatchdogSec seconds of
> >> suspending). I'm using master branch of systemd and the kernel. As
> >> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> >> not include suspend time.
> >>
> >> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> >> this patch series breaks systemd. If it's implemented correctly, you'd
> >> hope it *would* break it!
> >
> > This sounded a little weak on re-reading, sorry. So, I just confirmed
> > that after booting a "git revert -m 1 680014d6d1da", the issue no
> > longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> > any daemon getting killed).
> >
> > Let me know if I can help in any way.
> 
> Yea, this is the sort of thing I was worried about.
> 
> Thomas: I think reverting this change is needed.

Sigh. I hoped that something like this would be catched before I sent the
pull request by those who were actually interested in this change...

I'll try to distangle it.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[John Stultz]

On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> Quoting Genki Sky (2018/04/23 20:40:36 -0400)
>> I came across this thread for same reason as [0]: Daemons getting
>> killed by systemd on resume (after >WatchdogSec seconds of
>> suspending). I'm using master branch of systemd and the kernel. As
>> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
>> not include suspend time.
>>
>> Correct me if I'm mistaken, but I don't see the ambiguity of whether
>> this patch series breaks systemd. If it's implemented correctly, you'd
>> hope it *would* break it!
>
> This sounded a little weak on re-reading, sorry. So, I just confirmed
> that after booting a "git revert -m 1 680014d6d1da", the issue no
> longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> any daemon getting killed).
>
> Let me know if I can help in any way.

Yea, this is the sort of thing I was worried about.

Thomas: I think reverting this change is needed.

thanks
-john

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[John Stultz]

On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky  wrote:
> Quoting Genki Sky (2018/04/23 20:40:36 -0400)
>> I came across this thread for same reason as [0]: Daemons getting
>> killed by systemd on resume (after >WatchdogSec seconds of
>> suspending). I'm using master branch of systemd and the kernel. As
>> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
>> not include suspend time.
>>
>> Correct me if I'm mistaken, but I don't see the ambiguity of whether
>> this patch series breaks systemd. If it's implemented correctly, you'd
>> hope it *would* break it!
>
> This sounded a little weak on re-reading, sorry. So, I just confirmed
> that after booting a "git revert -m 1 680014d6d1da", the issue no
> longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
> any daemon getting killed).
>
> Let me know if I can help in any way.

Yea, this is the sort of thing I was worried about.

Thomas: I think reverting this change is needed.

thanks
-john

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Genki Sky]

Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> I came across this thread for same reason as [0]: Daemons getting
> killed by systemd on resume (after >WatchdogSec seconds of
> suspending). I'm using master branch of systemd and the kernel. As
> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> not include suspend time.
>
> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> this patch series breaks systemd. If it's implemented correctly, you'd
> hope it *would* break it!

This sounded a little weak on re-reading, sorry. So, I just confirmed
that after booting a "git revert -m 1 680014d6d1da", the issue no
longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
any daemon getting killed).

Let me know if I can help in any way.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Genki Sky]

Quoting Genki Sky (2018/04/23 20:40:36 -0400)
> I came across this thread for same reason as [0]: Daemons getting
> killed by systemd on resume (after >WatchdogSec seconds of
> suspending). I'm using master branch of systemd and the kernel. As
> mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
> not include suspend time.
>
> Correct me if I'm mistaken, but I don't see the ambiguity of whether
> this patch series breaks systemd. If it's implemented correctly, you'd
> hope it *would* break it!

This sounded a little weak on re-reading, sorry. So, I just confirmed
that after booting a "git revert -m 1 680014d6d1da", the issue no
longer appears. (I.e., a suspend for >WatchDog sec doesn't result in
any daemon getting killed).

Let me know if I can help in any way.

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Genki Sky]

  Hello,

I came across this thread for same reason as [0]: Daemons getting
killed by systemd on resume (after >WatchdogSec seconds of
suspending). I'm using master branch of systemd and the kernel. As
mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
not include suspend time.

Correct me if I'm mistaken, but I don't see the ambiguity of whether
this patch series breaks systemd. If it's implemented correctly, you'd
hope it *would* break it!

As a random end user, I see three options to get suspend/resume
working again on my laptop:

(A) Change systemd to keep track of the difference between
CLOCK_MONOTONIC and CLOCK_MONOTONIC_ACTIVE, using their difference via
clock_gettime(). This seems to be what the author of this patch series
intends (?).

(B) Implement timerfd_*(2) for CLOCK_MONOTONIC_ACTIVE in the kernel.
Do a sed s/CLOCK_MONOTONIC/&_ACTIVE in systemd source code.

(C) Do a 90% reverting of this patch series. Just introduce
CLOCK_MONOTONIC_ACTIVE as the "what you should use", document and
publicize this fact, and sometime in the future (monotonically
speaking :) finally unify CLOCK_MONOTONIC and CLOCK_BOOTTIME.

Thoughts?

Also, agreed, the missing break in do_clock_gettime() should be fixed,
as David mentioned in [1]. Is someone already patching this?

[0]: 
http://lkml.kernel.org/r/CANq1E4Tf27FJHTrO4ZVtWhYK=DLmwzszK=njopgxzzxqzao...@mail.gmail.com
[1]: 
http://lkml.kernel.org/r/canq1e4qppgaau5pybgpuc00s6wgqcat70z7cntzhilc6748...@mail.gmail.com

  Genki

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Genki Sky]

  Hello,

I came across this thread for same reason as [0]: Daemons getting
killed by systemd on resume (after >WatchdogSec seconds of
suspending). I'm using master branch of systemd and the kernel. As
mentioned, systemd uses CLOCK_MONOTONIC, originally expecting it to
not include suspend time.

Correct me if I'm mistaken, but I don't see the ambiguity of whether
this patch series breaks systemd. If it's implemented correctly, you'd
hope it *would* break it!

As a random end user, I see three options to get suspend/resume
working again on my laptop:

(A) Change systemd to keep track of the difference between
CLOCK_MONOTONIC and CLOCK_MONOTONIC_ACTIVE, using their difference via
clock_gettime(). This seems to be what the author of this patch series
intends (?).

(B) Implement timerfd_*(2) for CLOCK_MONOTONIC_ACTIVE in the kernel.
Do a sed s/CLOCK_MONOTONIC/&_ACTIVE in systemd source code.

(C) Do a 90% reverting of this patch series. Just introduce
CLOCK_MONOTONIC_ACTIVE as the "what you should use", document and
publicize this fact, and sometime in the future (monotonically
speaking :) finally unify CLOCK_MONOTONIC and CLOCK_BOOTTIME.

Thoughts?

Also, agreed, the missing break in do_clock_gettime() should be fixed,
as David mentioned in [1]. Is someone already patching this?

[0]: 
http://lkml.kernel.org/r/CANq1E4Tf27FJHTrO4ZVtWhYK=DLmwzszK=njopgxzzxqzao...@mail.gmail.com
[1]: 
http://lkml.kernel.org/r/canq1e4qppgaau5pybgpuc00s6wgqcat70z7cntzhilc6748...@mail.gmail.com

  Genki

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[David Herrmann]

Hi

On Fri, Apr 20, 2018 at 7:44 AM, Sergey Senozhatsky
 wrote:
> On (04/20/18 06:37), David Herrmann wrote:
>>
>> I get lots of timer-errors on Arch-Linux booting current master, after
>> a suspend/resume cycle. Just a selection of errors I see on resume:
>
> Hello David,
> Any chance you can revert the patches in question and test? I'm running
> ARCH (4.17.0-rc1-dbg-00042-gaa03ddd9c434) and suspend/resume cycle does
> not trigger any errors. Except for this one
>
> kernel: do_IRQ: 0.55 No irq handler for vector

I can easily reproduce it by sleeping for >5min, so the systemd
watchdog timers are triggered. The patches don't revert cleanly, so I
didn't look into booting without them, yet. I will try just linking
the monotonic clock to the monotonic_active clock later.

Also, doesn't this hunk in 72199320d49d need a 'break;':

diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index b258bee13b02..6259dbc0191a 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -73,6 +73,8 @@ int do_clock_gettime(clockid_t which_clock, struct
timespec64 *tp)
case CLOCK_BOOTTIME:
get_monotonic_boottime64(tp);
break;
+   case CLOCK_MONOTONIC_ACTIVE:
+   ktime_get_active_ts64(tp);
default:
return -EINVAL;
}

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[David Herrmann]

Hi

On Fri, Apr 20, 2018 at 7:44 AM, Sergey Senozhatsky
 wrote:
> On (04/20/18 06:37), David Herrmann wrote:
>>
>> I get lots of timer-errors on Arch-Linux booting current master, after
>> a suspend/resume cycle. Just a selection of errors I see on resume:
>
> Hello David,
> Any chance you can revert the patches in question and test? I'm running
> ARCH (4.17.0-rc1-dbg-00042-gaa03ddd9c434) and suspend/resume cycle does
> not trigger any errors. Except for this one
>
> kernel: do_IRQ: 0.55 No irq handler for vector

I can easily reproduce it by sleeping for >5min, so the systemd
watchdog timers are triggered. The patches don't revert cleanly, so I
didn't look into booting without them, yet. I will try just linking
the monotonic clock to the monotonic_active clock later.

Also, doesn't this hunk in 72199320d49d need a 'break;':

diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index b258bee13b02..6259dbc0191a 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -73,6 +73,8 @@ int do_clock_gettime(clockid_t which_clock, struct
timespec64 *tp)
case CLOCK_BOOTTIME:
get_monotonic_boottime64(tp);
break;
+   case CLOCK_MONOTONIC_ACTIVE:
+   ktime_get_active_ts64(tp);
default:
return -EINVAL;
}

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Sergey Senozhatsky]

On (04/20/18 06:37), David Herrmann wrote:
>
> I get lots of timer-errors on Arch-Linux booting current master, after
> a suspend/resume cycle. Just a selection of errors I see on resume:

Hello David,
Any chance you can revert the patches in question and test? I'm running
ARCH (4.17.0-rc1-dbg-00042-gaa03ddd9c434) and suspend/resume cycle does
not trigger any errors. Except for this one

kernel: do_IRQ: 0.55 No irq handler for vector

> systemd[1]: systemd-journald.service: Main process exited,
> code=dumped, status=6/ABRT
> rtkit-daemon[742]: The canary thread is apparently starving. Taking action.
> systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)!
> systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
> kernel: e1000e :00:1f.6: Failed to restore TIMINCA clock rate delta: -22
> 
> Lots of crashes with SIGABRT due to these.
> 
> I did not bisect it, but it sounds related to me. Also, user-space
> uses CLOCK_MONOTONIC for watchdog timers. That is, a process is
> required to respond to a watchdog-request in a given MONOTONIC
> time-frame. If this jumps during suspend/resume, watchdogs will fire
> immediately. I don't see how this can work with the new MONOTONIC
> behavior?

-ss

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Sergey Senozhatsky]

On (04/20/18 06:37), David Herrmann wrote:
>
> I get lots of timer-errors on Arch-Linux booting current master, after
> a suspend/resume cycle. Just a selection of errors I see on resume:

Hello David,
Any chance you can revert the patches in question and test? I'm running
ARCH (4.17.0-rc1-dbg-00042-gaa03ddd9c434) and suspend/resume cycle does
not trigger any errors. Except for this one

kernel: do_IRQ: 0.55 No irq handler for vector

> systemd[1]: systemd-journald.service: Main process exited,
> code=dumped, status=6/ABRT
> rtkit-daemon[742]: The canary thread is apparently starving. Taking action.
> systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)!
> systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
> kernel: e1000e :00:1f.6: Failed to restore TIMINCA clock rate delta: -22
> 
> Lots of crashes with SIGABRT due to these.
> 
> I did not bisect it, but it sounds related to me. Also, user-space
> uses CLOCK_MONOTONIC for watchdog timers. That is, a process is
> required to respond to a watchdog-request in a given MONOTONIC
> time-frame. If this jumps during suspend/resume, watchdogs will fire
> immediately. I don't see how this can work with the new MONOTONIC
> behavior?

-ss

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[David Herrmann]

Hey

On Tue, Mar 13, 2018 at 7:11 PM, John Stultz  wrote:
> On Mon, Mar 12, 2018 at 11:36 PM, Ingo Molnar  wrote:
>> Ok, I have edited all the changelogs accordingly (and also flipped around the
>> 'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' 
>> variant),
>> the resulting titles are (in order):
>>
>>  72199320d49d: timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
>>  d6ed449afdb3: timekeeping: Make the MONOTONIC clock behave like the 
>> BOOTTIME clock
>>  f2d6fdbfd238: Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
>>  d6c7270e913d: timekeeping: Remove boot time specific code
>>  7250a4047aa6: posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
>>  127bfa5f4342: hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
>>  92af4dcb4e1c: tracing: Unify the "boot" and "mono" tracing clocks
>>
>> I'll push these out after testing.
>
> I'm still anxious about userspace effects given how much I've seen the
> current behavior documented, and wouldn't pushed for this myself (I'm
> a worrier), but at least I'm not seeing any failures in initial
> testing w/ kselftest so far.

I get lots of timer-errors on Arch-Linux booting current master, after
a suspend/resume cycle. Just a selection of errors I see on resume:

systemd[1]: systemd-journald.service: Main process exited,
code=dumped, status=6/ABRT
rtkit-daemon[742]: The canary thread is apparently starving. Taking action.
systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)!
systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
kernel: e1000e :00:1f.6: Failed to restore TIMINCA clock rate delta: -22

Lots of crashes with SIGABRT due to these.

I did not bisect it, but it sounds related to me. Also, user-space
uses CLOCK_MONOTONIC for watchdog timers. That is, a process is
required to respond to a watchdog-request in a given MONOTONIC
time-frame. If this jumps during suspend/resume, watchdogs will fire
immediately. I don't see how this can work with the new MONOTONIC
behavior?

Thanks
David

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[David Herrmann]

Hey

On Tue, Mar 13, 2018 at 7:11 PM, John Stultz  wrote:
> On Mon, Mar 12, 2018 at 11:36 PM, Ingo Molnar  wrote:
>> Ok, I have edited all the changelogs accordingly (and also flipped around the
>> 'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' 
>> variant),
>> the resulting titles are (in order):
>>
>>  72199320d49d: timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
>>  d6ed449afdb3: timekeeping: Make the MONOTONIC clock behave like the 
>> BOOTTIME clock
>>  f2d6fdbfd238: Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
>>  d6c7270e913d: timekeeping: Remove boot time specific code
>>  7250a4047aa6: posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
>>  127bfa5f4342: hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
>>  92af4dcb4e1c: tracing: Unify the "boot" and "mono" tracing clocks
>>
>> I'll push these out after testing.
>
> I'm still anxious about userspace effects given how much I've seen the
> current behavior documented, and wouldn't pushed for this myself (I'm
> a worrier), but at least I'm not seeing any failures in initial
> testing w/ kselftest so far.

I get lots of timer-errors on Arch-Linux booting current master, after
a suspend/resume cycle. Just a selection of errors I see on resume:

systemd[1]: systemd-journald.service: Main process exited,
code=dumped, status=6/ABRT
rtkit-daemon[742]: The canary thread is apparently starving. Taking action.
systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)!
systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
kernel: e1000e :00:1f.6: Failed to restore TIMINCA clock rate delta: -22

Lots of crashes with SIGABRT due to these.

I did not bisect it, but it sounds related to me. Also, user-space
uses CLOCK_MONOTONIC for watchdog timers. That is, a process is
required to respond to a watchdog-request in a given MONOTONIC
time-frame. If this jumps during suspend/resume, watchdogs will fire
immediately. I don't see how this can work with the new MONOTONIC
behavior?

Thanks
David

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[John Stultz]

On Mon, Mar 12, 2018 at 11:36 PM, Ingo Molnar  wrote:
>
> * Linus Torvalds  wrote:
>
>> On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>> >
>> > This really needs lot of testing, documentation updates and more input from
>> > userspace folks to make a final decision.
>>
>> Honestly, I don't think we'd get the testing this kind of change needs
>> except by just trying it.
>>
>> I'm willing to merge this in the 4.17 merge window, with the
>> understanding that if people end up reporting issues, we may just have
>> to revert it all, and chalk it up to a learning experience - and add
>> the appropriate commentary in the kernel code about exactly what it
>> was that depended on that MONO/BOOT difference.
>>
>> One non-technical thing I would ask: use some other word than
>> "conflate". Maybe just "combine". Or better yet, "unify".
>
> Ok, I have edited all the changelogs accordingly (and also flipped around the
> 'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' 
> variant),
> the resulting titles are (in order):
>
>  72199320d49d: timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
>  d6ed449afdb3: timekeeping: Make the MONOTONIC clock behave like the BOOTTIME 
> clock
>  f2d6fdbfd238: Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
>  d6c7270e913d: timekeeping: Remove boot time specific code
>  7250a4047aa6: posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
>  127bfa5f4342: hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
>  92af4dcb4e1c: tracing: Unify the "boot" and "mono" tracing clocks
>
> I'll push these out after testing.

I'm still anxious about userspace effects given how much I've seen the
current behavior documented, and wouldn't pushed for this myself (I'm
a worrier), but at least I'm not seeing any failures in initial
testing w/ kselftest so far.

thanks
-john

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[John Stultz]

On Mon, Mar 12, 2018 at 11:36 PM, Ingo Molnar  wrote:
>
> * Linus Torvalds  wrote:
>
>> On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>> >
>> > This really needs lot of testing, documentation updates and more input from
>> > userspace folks to make a final decision.
>>
>> Honestly, I don't think we'd get the testing this kind of change needs
>> except by just trying it.
>>
>> I'm willing to merge this in the 4.17 merge window, with the
>> understanding that if people end up reporting issues, we may just have
>> to revert it all, and chalk it up to a learning experience - and add
>> the appropriate commentary in the kernel code about exactly what it
>> was that depended on that MONO/BOOT difference.
>>
>> One non-technical thing I would ask: use some other word than
>> "conflate". Maybe just "combine". Or better yet, "unify".
>
> Ok, I have edited all the changelogs accordingly (and also flipped around the
> 'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' 
> variant),
> the resulting titles are (in order):
>
>  72199320d49d: timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
>  d6ed449afdb3: timekeeping: Make the MONOTONIC clock behave like the BOOTTIME 
> clock
>  f2d6fdbfd238: Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
>  d6c7270e913d: timekeeping: Remove boot time specific code
>  7250a4047aa6: posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
>  127bfa5f4342: hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
>  92af4dcb4e1c: tracing: Unify the "boot" and "mono" tracing clocks
>
> I'll push these out after testing.

I'm still anxious about userspace effects given how much I've seen the
current behavior documented, and wouldn't pushed for this myself (I'm
a worrier), but at least I'm not seeing any failures in initial
testing w/ kselftest so far.

thanks
-john

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> >
> > This really needs lot of testing, documentation updates and more input from
> > userspace folks to make a final decision.
> 
> Honestly, I don't think we'd get the testing this kind of change needs
> except by just trying it.
> 
> I'm willing to merge this in the 4.17 merge window, with the
> understanding that if people end up reporting issues, we may just have
> to revert it all, and chalk it up to a learning experience - and add
> the appropriate commentary in the kernel code about exactly what it
> was that depended on that MONO/BOOT difference.
> 
> One non-technical thing I would ask: use some other word than
> "conflate". Maybe just "combine". Or better yet, "unify".

Ok, I have edited all the changelogs accordingly (and also flipped around the 
'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' variant), 
the resulting titles are (in order):

 72199320d49d: timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
 d6ed449afdb3: timekeeping: Make the MONOTONIC clock behave like the BOOTTIME 
clock
 f2d6fdbfd238: Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
 d6c7270e913d: timekeeping: Remove boot time specific code
 7250a4047aa6: posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
 127bfa5f4342: hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
 92af4dcb4e1c: tracing: Unify the "boot" and "mono" tracing clocks

I'll push these out after testing.

Thanks,

Ingo

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> >
> > This really needs lot of testing, documentation updates and more input from
> > userspace folks to make a final decision.
> 
> Honestly, I don't think we'd get the testing this kind of change needs
> except by just trying it.
> 
> I'm willing to merge this in the 4.17 merge window, with the
> understanding that if people end up reporting issues, we may just have
> to revert it all, and chalk it up to a learning experience - and add
> the appropriate commentary in the kernel code about exactly what it
> was that depended on that MONO/BOOT difference.
> 
> One non-technical thing I would ask: use some other word than
> "conflate". Maybe just "combine". Or better yet, "unify".

Ok, I have edited all the changelogs accordingly (and also flipped around the 
'clock MONOTONIC' language to the more readable 'the MONOTONIC clock' variant), 
the resulting titles are (in order):

 72199320d49d: timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
 d6ed449afdb3: timekeeping: Make the MONOTONIC clock behave like the BOOTTIME 
clock
 f2d6fdbfd238: Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
 d6c7270e913d: timekeeping: Remove boot time specific code
 7250a4047aa6: posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
 127bfa5f4342: hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
 92af4dcb4e1c: tracing: Unify the "boot" and "mono" tracing clocks

I'll push these out after testing.

Thanks,

Ingo

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 1 Mar 2018, Thomas Gleixner wrote:
> On Thu, 1 Mar 2018, Linus Torvalds wrote:
> > On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> > >
> > > This really needs lot of testing, documentation updates and more input 
> > > from
> > > userspace folks to make a final decision.
> > 
> > Honestly, I don't think we'd get the testing this kind of change needs
> > except by just trying it.
> > 
> > I'm willing to merge this in the 4.17 merge window, with the
> > understanding that if people end up reporting issues, we may just have
> > to revert it all, and chalk it up to a learning experience - and add
> > the appropriate commentary in the kernel code about exactly what it
> > was that depended on that MONO/BOOT difference.
> 
> Fair enough. So we maybe just merge the first two patches and merge the
> cleanups and consolidation patches when we feel good enough.
> 
> I surely can queue the whole lot in next, but from PTI the experience I
> know how good the test coverage is. 4.14.stable would be the ideal testing
> ground. /me runs fast and hides

That said, at least the people who are asking for that should provide
testing results _before_ this gets applied or merged upstream.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 1 Mar 2018, Thomas Gleixner wrote:
> On Thu, 1 Mar 2018, Linus Torvalds wrote:
> > On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> > >
> > > This really needs lot of testing, documentation updates and more input 
> > > from
> > > userspace folks to make a final decision.
> > 
> > Honestly, I don't think we'd get the testing this kind of change needs
> > except by just trying it.
> > 
> > I'm willing to merge this in the 4.17 merge window, with the
> > understanding that if people end up reporting issues, we may just have
> > to revert it all, and chalk it up to a learning experience - and add
> > the appropriate commentary in the kernel code about exactly what it
> > was that depended on that MONO/BOOT difference.
> 
> Fair enough. So we maybe just merge the first two patches and merge the
> cleanups and consolidation patches when we feel good enough.
> 
> I surely can queue the whole lot in next, but from PTI the experience I
> know how good the test coverage is. 4.14.stable would be the ideal testing
> ground. /me runs fast and hides

That said, at least the people who are asking for that should provide
testing results _before_ this gets applied or merged upstream.

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Steven Rostedt]

On Thu, 1 Mar 2018 19:41:35 +0100 (CET)
Thomas Gleixner  wrote:

> I'm old enough to have learned that conflate means unify or combine, but
> I'm still not old enough to be stubborn about it :)

You need to watch more American Cable News channels to know what
"conflate" means today.

-- Steve

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Steven Rostedt]

On Thu, 1 Mar 2018 19:41:35 +0100 (CET)
Thomas Gleixner  wrote:

> I'm old enough to have learned that conflate means unify or combine, but
> I'm still not old enough to be stubborn about it :)

You need to watch more American Cable News channels to know what
"conflate" means today.

-- Steve

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 1 Mar 2018, Linus Torvalds wrote:
> On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> >
> > This really needs lot of testing, documentation updates and more input from
> > userspace folks to make a final decision.
> 
> Honestly, I don't think we'd get the testing this kind of change needs
> except by just trying it.
> 
> I'm willing to merge this in the 4.17 merge window, with the
> understanding that if people end up reporting issues, we may just have
> to revert it all, and chalk it up to a learning experience - and add
> the appropriate commentary in the kernel code about exactly what it
> was that depended on that MONO/BOOT difference.

Fair enough. So we maybe just merge the first two patches and merge the
cleanups and consolidation patches when we feel good enough.

I surely can queue the whole lot in next, but from PTI the experience I
know how good the test coverage is. 4.14.stable would be the ideal testing
ground. /me runs fast and hides

> One non-technical thing I would ask: use some other word than
> "conflate". Maybe just "combine". Or better yet, "unify".
> 
> "Conflate" technically and historically means the same thing as
> combine, but has very much gathered a side meaning of "confuse".
> 
> So yes, "conflate" is indeed about mixing or combining, but it's
> typically used in the sense of a *bad* combination or mixing. So
> "trying to conflate two issues" means "trying to mix two issues that
> are not the same into one".
> 
> So "unify" and "conflate" mean both the same thing and almost exactly
> the opposite at the same time.
> 
> And yes, you will find dictionaries (and linguists) that hold purely
> to the old meaning. As always, there are fogeys that can't get over
> the fact that meanings meander and change.

I'm old enough to have learned that conflate means unify or combine, but
I'm still not old enough to be stubborn about it :)

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Thomas Gleixner]

On Thu, 1 Mar 2018, Linus Torvalds wrote:
> On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
> >
> > This really needs lot of testing, documentation updates and more input from
> > userspace folks to make a final decision.
> 
> Honestly, I don't think we'd get the testing this kind of change needs
> except by just trying it.
> 
> I'm willing to merge this in the 4.17 merge window, with the
> understanding that if people end up reporting issues, we may just have
> to revert it all, and chalk it up to a learning experience - and add
> the appropriate commentary in the kernel code about exactly what it
> was that depended on that MONO/BOOT difference.

Fair enough. So we maybe just merge the first two patches and merge the
cleanups and consolidation patches when we feel good enough.

I surely can queue the whole lot in next, but from PTI the experience I
know how good the test coverage is. 4.14.stable would be the ideal testing
ground. /me runs fast and hides

> One non-technical thing I would ask: use some other word than
> "conflate". Maybe just "combine". Or better yet, "unify".
> 
> "Conflate" technically and historically means the same thing as
> combine, but has very much gathered a side meaning of "confuse".
> 
> So yes, "conflate" is indeed about mixing or combining, but it's
> typically used in the sense of a *bad* combination or mixing. So
> "trying to conflate two issues" means "trying to mix two issues that
> are not the same into one".
> 
> So "unify" and "conflate" mean both the same thing and almost exactly
> the opposite at the same time.
> 
> And yes, you will find dictionaries (and linguists) that hold purely
> to the old meaning. As always, there are fogeys that can't get over
> the fact that meanings meander and change.

I'm old enough to have learned that conflate means unify or combine, but
I'm still not old enough to be stubborn about it :)

Thanks,

tglx

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Linus Torvalds]

On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>
> This really needs lot of testing, documentation updates and more input from
> userspace folks to make a final decision.

Honestly, I don't think we'd get the testing this kind of change needs
except by just trying it.

I'm willing to merge this in the 4.17 merge window, with the
understanding that if people end up reporting issues, we may just have
to revert it all, and chalk it up to a learning experience - and add
the appropriate commentary in the kernel code about exactly what it
was that depended on that MONO/BOOT difference.

One non-technical thing I would ask: use some other word than
"conflate". Maybe just "combine". Or better yet, "unify".

"Conflate" technically and historically means the same thing as
combine, but has very much gathered a side meaning of "confuse".

So yes, "conflate" is indeed about mixing or combining, but it's
typically used in the sense of a *bad* combination or mixing. So
"trying to conflate two issues" means "trying to mix two issues that
are not the same into one".

So "unify" and "conflate" mean both the same thing and almost exactly
the opposite at the same time.

And yes, you will find dictionaries (and linguists) that hold purely
to the old meaning. As always, there are fogeys that can't get over
the fact that meanings meander and change.

   Linus

Re: [RFC/RFT patch 0/7] timekeeping: Unify clock MONOTONIC and clock BOOTTIME

[Linus Torvalds]

On Thu, Mar 1, 2018 at 8:33 AM, Thomas Gleixner  wrote:
>
> This really needs lot of testing, documentation updates and more input from
> userspace folks to make a final decision.

Honestly, I don't think we'd get the testing this kind of change needs
except by just trying it.

I'm willing to merge this in the 4.17 merge window, with the
understanding that if people end up reporting issues, we may just have
to revert it all, and chalk it up to a learning experience - and add
the appropriate commentary in the kernel code about exactly what it
was that depended on that MONO/BOOT difference.

One non-technical thing I would ask: use some other word than
"conflate". Maybe just "combine". Or better yet, "unify".

"Conflate" technically and historically means the same thing as
combine, but has very much gathered a side meaning of "confuse".

So yes, "conflate" is indeed about mixing or combining, but it's
typically used in the sense of a *bad* combination or mixing. So
"trying to conflate two issues" means "trying to mix two issues that
are not the same into one".

So "unify" and "conflate" mean both the same thing and almost exactly
the opposite at the same time.

And yes, you will find dictionaries (and linguists) that hold purely
to the old meaning. As always, there are fogeys that can't get over
the fact that meanings meander and change.

   Linus