[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171115181531.322572387@linutronix.de>
Date: Wed, 15 Nov 2017 19:15:31 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: LKML <linux-kernel@...r.kernel.org>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>,
Prarit Bhargava <prarit@...hat.com>,
Mark Salyzyn <salyzyn@...roid.com>,
Petr Mladek <pmladek@...e.com>, Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Joe Perches <joe@...ches.com>
Subject: [RFC patch 0/7] printk: Switch to CLOCK_MONOTONIC and store extra
time stamps
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
Powered by blists - more mailing lists