All of 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

  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 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.