Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752710Ab2EMLI1 (ORCPT ); Sun, 13 May 2012 07:08:27 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:54293 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751945Ab2EMLIZ convert rfc822-to-8bit (ORCPT ); Sun, 13 May 2012 07:08:25 -0400 MIME-Version: 1.0 In-Reply-To: References: <1336475689.1179.12.camel@mop> <1336571457.30189.29.camel@joe2Laptop> <20120509230649.GA10695@kroah.com> <1336617045.25027.2.camel@mop> <20120511151944.GA6990@kroah.com> From: Kay Sievers Date: Sun, 13 May 2012 13:08:04 +0200 Message-ID: Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer To: Linus Torvalds Cc: Sasha Levin , Greg KH , Yinghai Lu , Joe Perches , Ingo Molnar , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3243 Lines: 82 On Sat, May 12, 2012 at 8:35 PM, Linus Torvalds wrote: > On Sat, May 12, 2012 at 12:43 AM, Sasha Levin wrote: >> >> So I got something like this: >> >> # sleep 61 ; echo foo > /dev/kmsg ; sleep 61 ; echo bar > /dev/kmsg ; >> sleep 5 ; echo zoot > /dev/kmsg ; sleep 10 ; echo foo > /dev/kmsg ; >> echo bar > /dev/kmsg ; sleep 61 ; echo zoot > /dev/kmsg ; echo foo > >> /dev/kmsg >> >> [  673.222632] foo >> [  734.315249] bar >> [   +5.077527] zoot >> [  +10.235225] foo >> [   +0.002971] bar >> [  810.883085] zoot >> [   +0.003081] foo >> >> If that looks right, I can send a patch once this printf overhaul is >> stable, unless Kay already plans on doing it as part of his work. > > So judging by my own use, I really think that > >  (a) the microseconds are *totally* useless for the absolute time. In > fact, they are worse than useless: they take up space and are actively > distracting. > >      If the last message was over a minute ago, *nobody* cares about > the microsecond. The microseconds are useful when there are multiple > messages and you see that "oh, those events happened within a couple > of ms of each other", but for the absolute time they are just bad. > >     Even the *seconds* are probably not that interesting. > >  (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 dunno. The above is what I would have liked to see quite often. I > look at dmesg, and notice that I had an WARN_ON_ONCE in it, and I have > no idea when it happened, because the "seconds since boot" is totally > useless information for me, as I'm too lazy to try to use /proc/uptime > to calculate what it is. Yeah, that looks generally more useful. "dmesg -T" tries to translate that to wall clock time too. At the moment, it can't really do that reliable at the point of reading the timestamps though, because the monotonic time used does not include the time spent in suspend. One other problem with the current logic is that the timestamp we get at the moment is not guaranteed to monotonic, log lines from different CPUs at the same time can jump forth and back, so the relative-time calculation could, with the current code, show negative values. Not sure what options we have to use a more better clock source, if things are expected to work in NMIs and IRQs. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/