public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: 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>,
	John Stultz <john.stultz@linaro.org>
Subject: Re: [GIT pull] printk updates for 4.15
Date: Thu, 16 Nov 2017 08:12:23 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1711160804350.2265@nanos> (raw)
In-Reply-To: <CA+55aFytxdwLTQYKWsUJDbrEUYEQr7dzH9NoaKAF-LDnyb2_sA@mail.gmail.com>

On Wed, 15 Nov 2017, Linus Torvalds wrote:
> On Wed, Nov 15, 2017 at 4:37 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > 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.
> 
> Ahh, now that you mention it, I remember that. Things coming to a
> complete halt because every single X event timer and network timer all
> firing at resume.
> 
> If the timer wheel thing doesn't happen any more, I'd still be willing
> to try it out, but you're right, it might be much worse than I
> thought.

The timer wheel part is easy to cure, we actually tried that back then by
advancing clock monotonic, but not jiffies. That made at least most of the
kernel side issues go away, but the user space wreckage persisted and we
saw now way to fix that w/o violating the no user space visible regression
rule.

It might be better now, so yes might can try and see what happens. The
android folks surely an run a quick coverage test on their side, but we'd
need to get some serious feedback from desktop and enterprise people as
well.

The first thing we need to look at before even going there is stuff like
NTP which needs the coupling of MONOTONIC and MONOTONIC_RAW preserved. I
need to make sure that this does not break in the first place.

I hope that I can find a few spare cycles to whip up a POC patch which does
not make stuff fall apart immediately.

Thanks,

	tglx

  reply	other threads:[~2017-11-16  7:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13  9:36 [GIT pull] printk updates for 4.15 Thomas Gleixner
2017-11-14  1:18 ` Linus Torvalds
2017-11-14  2:48   ` Linus Torvalds
2017-11-14 10:03   ` Petr Mladek
2017-11-14 13:28     ` Prarit Bhargava
2017-11-14 15:56     ` Mark Salyzyn
2017-11-15  0:48       ` Sergey Senozhatsky
2017-11-14 17:20     ` Linus Torvalds
2017-11-14 20:21       ` Thomas Gleixner
2017-11-14 21:07         ` Linus Torvalds
2017-11-14 21:09           ` Thomas Gleixner
2017-11-14 21:16           ` Mark Salyzyn
2017-11-14 21:29             ` Linus Torvalds
2017-11-14 22:10               ` Mark Salyzyn
2017-11-14 22:37                 ` Linus Torvalds
2017-11-14 22:50                   ` Thomas Gleixner
2017-11-14 23:00                     ` Joe Perches
2017-11-14 23:00                     ` Linus Torvalds
2017-11-14 23:04                       ` Thomas Gleixner
2017-11-14 23:18                         ` Linus Torvalds
2017-11-14 23:22                           ` Thomas Gleixner
2017-11-15  0:00                     ` Linus Torvalds
2017-11-15  8:04                       ` Ingo Molnar
2017-11-15 16:26                       ` Mark Salyzyn
2017-11-15 17:42                         ` Linus Torvalds
2017-11-16  0:37                           ` Thomas Gleixner
2017-11-16  1:23                             ` John Stultz
2017-11-16  1:32                             ` Linus Torvalds
2017-11-16  7:12                               ` Thomas Gleixner [this message]
2017-11-18  0:26                                 ` Thomas Gleixner
2017-11-18  0:44                                   ` Linus Torvalds
2017-11-18  1:00                                     ` Thomas Gleixner
2017-11-20  6:20                                   ` Kevin Easton
2017-11-20  6:36                                     ` Linus Torvalds
2018-01-29 20:34                     ` Mark Salyzyn
2018-01-29 21:49                       ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1711160804350.2265@nanos \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=prarit@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=salyzyn@android.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox