From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753254AbdK1U3m (ORCPT ); Tue, 28 Nov 2017 15:29:42 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:46965 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbdK1U3l (ORCPT ); Tue, 28 Nov 2017 15:29:41 -0500 X-Google-Smtp-Source: AGs4zMbbh+gbm40UDAWjjkqFtYPqM043R7HzELEqOb0KZ3xqb+LDrP9UtMlNR7lOjgIbloVL9etX+Q== Subject: Re: [RFC patch 7/7] timekeeping: Hack to use fine grained timestamps during boot To: Steven Rostedt Cc: Prarit Bhargava , Petr Mladek , Thomas Gleixner , LKML , Linus Torvalds , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Andrew Morton , Sergey Senozhatsky , Joe Perches 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> From: Mark Salyzyn Message-ID: <595323bb-85a4-973f-5ca6-aaa80e6000c5@android.com> Date: Tue, 28 Nov 2017 12:29:38 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20171128144500.190aa85c@gandalf.local.home> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/28/2017 11:45 AM, Steven Rostedt wrote: > On Tue, 28 Nov 2017 11:10:02 -0800 > Mark Salyzyn 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