linux-kernel - Re: [PATCH 06/23 -v8] handle accurate time keeping over long delays

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1201800297.6789.14.camel@jstultz-laptop>
Date:	Thu, 31 Jan 2008 09:24:57 -0800
From:	John Stultz <johnstul@...ibm.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Bird <tim.bird@...sony.com>,
	Sam Ravnborg <sam@...nborg.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 06/23 -v8] handle accurate time keeping over long delays

On Thu, 2008-01-31 at 07:10 -0500, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@...dmis.org) wrote:
> > From: John Stultz <johnstul@...ibm.com>
> > 
> > Handle accurate time even if there's a long delay between
> > accumulated clock cycles.
> > 
> 
> About this one.. we talked a lot about the importance of timekeeping at
> the first Montreal Tracing Summit this week. Actually, someone
> mentioned a very interesting point : in order to be able to synchronize
> traces taken from the machine with traces taken on external hardware
> (i.e. memory bus tracer on Freescale), taking the "real" counter value
> rather that using the "cumulated cycles" approach (which creates a
> virtual counted instead) would be better.
> 
> So I would recommend using an algorithm that would return a clock value
> which is the same as the underlying hardware counter.

Hmm. It is an interesting issue. Clearly having the raw cycle value
match up so hardware analysis could be mapped to software timestamps
would be useful(although obscure) feature. However with the variety of
clocksources, dealing properly with the clocksource wrap issue (ACPI PM
for instance wraps about every 5 seconds) also has to be addressed.

I think you were mentioning an idea that required some work on the read
side to handle the wraps, basically managing the high order bits by
hand. This sounds like it would be an additional feature that could be
added on to the infrastructure being provided in the
get_monotonic_cycles() patch. No?

However, all of the above is a separate issue then what this (the
timekeeping over long delay) patch addresses, as it is not really
directly related to the get_monotonic_cycles() patch, but instead allows
for correct timekeeping, making update_wall_time() to function properly
if it was deferred for longer then the clocksource's wrap time.

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/