LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Salyzyn <salyzyn@android.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Prarit Bhargava <prarit@redhat.com>,
Petr Mladek <pmladek@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linuxfoundation.org>,
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>,
Joe Perches <joe@perches.com>
Subject: Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot
Date: Tue, 28 Nov 2017 12:29:38 -0800 [thread overview]
Message-ID: <595323bb-85a4-973f-5ca6-aaa80e6000c5@android.com> (raw)
In-Reply-To: <20171128144500.190aa85c@gandalf.local.home>
On 11/28/2017 11:45 AM, Steven Rostedt wrote:
> On Tue, 28 Nov 2017 11:10:02 -0800
> Mark Salyzyn <salyzyn@android.com> wrote:
>
>> There is no guarantee of sequential order of delivery for kernel prints.
> But isn't the timestamp taken with the logbuf_lock, and then delivered
> to the printk buffer? That would guarantee that all events will be in
> order, and the timestamps be sequential. They are serialized by the
> logbuf_lock.
>
> -- Steve
To get closer to a sequential order of event delivery by timestamp, you
really should take a global timestamp (I know, local clock is _not_ a
global timestamp) first thing and as close to the event as possible,
before anything else, and outside of a lock which is merely a
synchronization action.
A) event came first, got preempted by the scheduler before lock.
B) multiple events came in order while lock held, random selection of
which one gets the lock once released.
C) scheduling differences between FIFO, BATCH, low priority, cgroup
limits, interrupt, especially since an event is usually generated
_after_ the fact related to an activity.
We do not have a guarantee of sequential order, outside the scope of
this RFC. We accept this behavior as it is good enough for the most
part, and we are all smart adults here, we can figure it out when things
get strange.
-- Mark
next prev parent reply other threads:[~2017-11-28 20:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-15 18:15 [RFC patch 0/7] printk: Switch to CLOCK_MONOTONIC and store extra time stamps Thomas Gleixner
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 [this message]
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=595323bb-85a4-973f-5ca6-aaa80e6000c5@android.com \
--to=salyzyn@android.com \
--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=sergey.senozhatsky@gmail.com \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).