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:	Thu, 25 Sep 2008 11:26:20 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.org>,
	Martin Bligh <mbligh@...gle.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	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


On Thu, 25 Sep 2008, Linus Torvalds wrote:
> On Thu, 25 Sep 2008, Peter Zijlstra wrote:
> > 
> > Right - if you use raw tsc you're dependent on clock speed, if we'd
> > normalize that on ns instead you'd need at least: [...]
> 
> Please don't normalize to ns.
> 
> It's really quite hard, and it's rather _expensive_ on many CPU's. It 
> involves a non-constant 64-bit divide, after all. I bet it can be 
> optimized to be a multiply-by-inverse instead, but it would be a 128-bit 
> (or maybe just 96-bit?) multiply, and the code would be nasty, and likely 
> rather more expensive than the TSC reading itself.
> 
> Sure, you have to normalize at _some_ point, and normalizing early might 
> make some things simpler, but the main thing that would become easier is 
> people messing about in the raw log buffer on their own directly, which 
> would hopefully be something that we'd discourage _anyway_ (ie we should 
> try to use helper functions for people to do things like "get the next 
> event data", not only because the headers are going to be odd due to 
> trying to pack things together, but because maybe we can more easily 
> extend on them later that way when nobody accesses the headers by hand).
> 
> And I don't think normalizing later is in any way more fundamentally hard. 
> It just means that you do part of the expensive things after you have 
> gathered the trace, rather than during.

I've been just using sched_clock() which already normalizes to ns. But I 
use a wrapper (ring_buffer_time_stamp) so we can decide on how to keep 
track later.

If we do not normalize, then we must come up yet another generic way to read 
the CPU clock for all archs. And then we also need to come up with another 
generic way to normalize it later for output.

If I'm missing that this already exists, then I'll go and use it, but I do 
not think that tracing is worthy enough to implement this timing 
infrastructure just to get faster traces.

-- Steve

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