From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S932221AbdK1Uiu (ORCPT <rfc822;w@1wt.eu>);
        Tue, 28 Nov 2017 15:38:50 -0500
Received: from merlin.infradead.org ([205.233.59.134]:58596 "EHLO
        merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752018AbdK1Uis (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 28 Nov 2017 15:38:48 -0500
Date: Tue, 28 Nov 2017 21:38:34 +0100
From: Peter Zijlstra <peterz@infradead.org>
To: Mark Salyzyn <salyzyn@android.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
        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>,
        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
Message-ID: <20171128203834.tovqh4xkbrqkf4ht@hirez.programming.kicks-ass.net>
References: <20171115181531.322572387@linutronix.de>
 <20171115182657.703928462@linutronix.de>
 <20171123125823.gnhwtnx6bxd3tb4q@pathway.suse.cz>
 <205229e2-fab4-31cb-60cd-f36bc2228804@redhat.com>
 <26f1d1fd-ed65-73d1-8278-8058b6b83a3e@android.com>
 <20171128144500.190aa85c@gandalf.local.home>
 <595323bb-85a4-973f-5ca6-aaa80e6000c5@android.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <595323bb-85a4-973f-5ca6-aaa80e6000c5@android.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Nov 28, 2017 at 12:29:38PM -0800, Mark Salyzyn wrote:
> 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)

it is if you have a halfway sane machine