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:	Wed, 24 Sep 2008 13:39:54 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Martin Bligh <mbligh@...gle.com>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	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 Wed, 24 Sep 2008, Martin Bligh wrote:
> 
> If we use 32 bits instead of 27, then the timestamp events are only
> about once per second, which is probably fine for overhead ... ?

You'd have them ONCE IN A BLUE MOON.

If there is nothing going on, you don't need the timestamps at all.

Yes, some people will _want_ a heartbeat, of course, and there might be 
serialization points where we want to serialize some external clock to the 
TSC, but that's a separate issue from generating a full TSC value. We may 
well decide that once a second we want a whole packet with TSC _and_ 
HR-timer sync information, for example. But that's a separate issue.

And if there is a lot of things going on (eg you're tracing things like a 
block device performance issue), you have events _much_ closer to each 
other than 1/30th of a second, and you again _never_ need a full 59-bit 
timestamp. Because the delta would be cumulative, and as long as you are 
generating events, you're also updating the base TSC.

The only case you'll see lots of those timestamps (where "lots" is 
guaranteed to be less than 30 in one second) would be if you're tracing 
something that literally does a couple of events per second. But then you 
sure as hell don't need to worry about performance _or_ memory use. If you 
have some trace that gives you five hits per second (and spread out, to 
boot!), you'll generate twice the number of trace entries because each 
entry would always be preceded by an extended thing, but hey, do we really 
worry about five trace events per second?

And quite frankly, most of the tracing I've ever done really does fall 
into the "either nothing" or "a flood of events" thing. The "5-25 events 
per second at regular intervals" case really doesn't sound very common at 
all - not that I would worry about it if it was since it's going to be a 
really simple case..

And btw, this would be an issue only on really fast CPU's anyway. If 
you're in the mobile space, your TSC will be clocking at less than that, 
so the slower the machine, the less the overhead. Again, that's exactly 
what you want - the overhead is not some fixed thing that is detemined by 
the fastest possible TSC and hurts slower machines too, it's relative to 
the speed of the machine itself.

(Of course, with cpufreq and fixed TSC's, a 2GHz CPU will have a 2GHz TSC 
even when it's running at just 1GHz, but the worry is more about trying to 
trace on an embedded board with some pitiful 500MHz thing that is pretty 
overworked anyway).

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