linux-kernel - Re: [RFC PATCH 1/3] Unified trace buffer

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]

Date:	Fri, 26 Sep 2008 00:55:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	prasad@...ux.vnet.ibm.com,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	David Wilder <dwilder@...ibm.com>, hch@....de,
	Tom Zanussi <zanussi@...cast.net>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 1/3] Unified trace buffer

* Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> Linus Torvalds wrote:

> > The reason I say "and no" is that it's not technically really 
> > possible to atomically give the exact TSC at which the frequency 
> > change took place. We just don't have the information, and I doubt 
> > we will ever have it.
> 
> Well, you don't need the tsc at the precise moment of the frequency 
> change.  You just need to emit the current tsc+frequency+wallclock 
> time before you emit any more delta records after the frequency 
> change.  You can't fetch all those values instantaneously, but you can 
> get close.

hm, i'm not sure you've thought through this delta record idea.

Take a system that goes idle thousands of times a second. (it's easy - 
just some networking workload)

Now take a tracer that just wants to emit a trace entry every now and 
then. Once or twice a second or so.

Note that suddenly you have thousands of totally artificial 'delta' time 
records between two real events, and have to post-process all your way 
up between these events to get to the real timeline.

... it is totally impractical and costly.

and then i havent even mentioned some other big complications:

 - the numeric errors that mount up over thousands of delta events

 - the memory overhead over thousands of entries

 - the fact that cpufreq and PLL changes are rarely atomic and that the
   TSC can flip-flop between two frequencies.

TSC based delta time post-processing is just not practical. Micro-time 
has to be synced up to GTOD in some manner - OR you might declare that 
the TSC _has_ to never stop and has to be constant. (no modern x86 CPU 
meets that criterium at the moment though.)

... and the moment you accept the fact that the GTOD _has_ to be mixed 
into it, all the rest follows pretty much automatically: either you 
store the (GTOD,freq,TSC) triple and post-process that absolute 
timestamp, and you accept the in-memory cost of that and do 
post-processing, or you compress that triple in situ and store the 
result only.

[ You will then also want some fall-back implementation for CPUs that 
  have no TSCs, and for architectures that have no default 
  implementation - something jiffies based. And you want some special 
  hooks for paravirt, as always. ]

I.e. you will end up having something quite close to 
cpu_clock()/sched_clock().

_Or_ if you manage to get any better than that for tracing then please 
tell us about it because we want to apply those concepts to 
cpu_clock()/sched_clock() too :-)

	Ingo
--
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/