All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linuxfoundation.org>,
	Prarit Bhargava <prarit@redhat.com>,
	Mark Salyzyn <salyzyn@android.com>,
	Petr Mladek <pmladek@suse.com>, Ingo Molnar <mingo@kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Joe Perches <joe@perches.com>
Subject: [RFC patch 0/7] printk: Switch to CLOCK_MONOTONIC and store extra time stamps
Date: Wed, 15 Nov 2017 19:15:31 +0100	[thread overview]
Message-ID: <20171115181531.322572387@linutronix.de> (raw)

Following up on yesterdays discussion about adding support for reliably
correlatable time stamps to the printk ringbuffer entries, I split up that
draft patch from yesterday, addressed review feedback and actually tested
it.

There are a few things which are visible changes:

1) The fine grained time stamps start later in the boot process because
   local_clock() is initialized before a high resolution clocksource is
   installed.

2) During suspend/resume between timekeeping_suspend() and
   timekeeping_resume() the NMI safe accessors return a stale timestamp,
   i.e. the timestamp which was captured in timekeeping_suspend()

Mitigation:

 #1 Can be mitigated by a horrible hack, which I added as last patch in the
    series. It uses local_clock() in early boot up to the point where a
    proper clocksource providing fine grained CLOCK_MONOTONIC is
    available. That's actually not that bad, because time won't drift apart.

 #2 Can be mitigated at least for clocksources which are safe to access past
    timekeeping_suspend(). There are patches which enable that for TSC when
    the TSC_NONSTOP_SUSPEND cpu feature bit is enabled.

    For clocksources which cannot be accessed past timekeeping_suspend()
    the workaround #1 can be used (see last patch^Whack). Though this might
    cause time inconsistencies (non monotonic time stamps).

Not sure if any of this is a real problem, because not all
local/sched_clock() implementations are functional past
timekeeping_suspend(). 

I left all 3 time stamps in the patch for now so people can actually play
with that.

Thanks,

	tglx

             reply	other threads:[~2017-11-15 18:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 18:15 Thomas Gleixner [this message]
2017-11-15 18:15 ` [RFC patch 1/7] timekeeping: Do not unconditionally suspend NMI safe timekeepers Thomas Gleixner
2017-11-15 18:15 ` [RFC patch 2/7] x86/tsc: Set clocksource CLOCK_SOURCE_SUSPEND_ACCESS_OK Thomas Gleixner
2017-11-15 18:15 ` [RFC patch 3/7] printk: Use clock MONOTONIC for timestamps Thomas Gleixner
2017-11-16  7:58   ` Sergey Senozhatsky
2017-11-15 18:15 ` [RFC patch 4/7] timekeeping: Add NMI safe accessor to mono/boot/real clocks Thomas Gleixner
2017-11-17 23:00   ` Steven Rostedt
2017-11-17 23:12     ` Linus Torvalds
2017-11-17 23:43       ` Thomas Gleixner
2017-11-15 18:15 ` [RFC patch 5/7] crash: Add VMCOREINFO_FIELD_AND_OFFSET() Thomas Gleixner
2017-11-23 12:46   ` Petr Mladek
2017-11-15 18:15 ` [RFC patch 6/7] printk: Store mono/boot/real time timestamps Thomas Gleixner
2017-11-23 13:36   ` Petr Mladek
2017-11-15 18:15 ` [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot Thomas Gleixner
2017-11-23 12:58   ` Petr Mladek
2017-11-28 18:43     ` Prarit Bhargava
2017-11-28 18:47       ` Thomas Gleixner
2017-12-08 11:23         ` Petr Mladek
2017-12-08 19:51           ` Thomas Gleixner
2017-11-28 19:10       ` Mark Salyzyn
2017-11-28 19:45         ` Steven Rostedt
2017-11-28 20:29           ` Mark Salyzyn
2017-11-28 20:38             ` Peter Zijlstra

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=20171115181531.322572387@linutronix.de \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=joe@perches.com \
    --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@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.