From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965267Ab2EQDot (ORCPT ); Wed, 16 May 2012 23:44:49 -0400 Received: from terminus.zytor.com ([198.137.202.10]:58050 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760958Ab2EQDos (ORCPT ); Wed, 16 May 2012 23:44:48 -0400 Message-ID: <4FB47420.7050003@kernel.org> Date: Wed, 16 May 2012 20:44:32 -0700 From: "H. Peter Anvin" Organization: Linux Kernel Organization, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Linus Torvalds CC: Sasha Levin , Kay Sievers , Greg KH , Yinghai Lu , Joe Perches , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer References: <1336475689.1179.12.camel@mop> <1336571457.30189.29.camel@joe2Laptop> <20120509230649.GA10695@kroah.com> <1336617045.25027.2.camel@mop> <20120511151944.GA6990@kroah.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/12/2012 11:35 AM, Linus Torvalds wrote: > > (b) The one thing I have often wanted is not "after how many seconds > of boot", but "when". So it would actually be nice if the absolute > time was converted into local time. The kernel can actually do that, > so I suspect that the best format for the relative timestamps would > really be something like > > > [May12 11:27] foo > > [May12 11:28] bar > > [ +5.077527] zoot > > [ +10.235225] foo > > [ +0.002971] bar > > [May12 11:29] zoot > > [ +0.003081] foo > > because that would be really useful sometimes. > > (And no, never mind the year. If you log those things long-term, the > year will be in the full log, so logging the year in the dmesg is just > pointless.) I would like to give a +1 on absolute time, and -1 on local timezone and a -$LARGE_NUMBER on low resolution. Why? Getting events accurately timed across multiple hosts can be really useful when trying to reconstruct, ahem, "network events". Getting UTC time at some fairly high resolution is useful for that. I would say the useful resolution is probably milliseconds. -hpa