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 13:02:26 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Mathieu Desnoyers <compudj@...stal.dyndns.org>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.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, "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, Mathieu Desnoyers wrote:
> > 
> > I remembered other concerns about 27 vs 32 bits TSC decision, which are
> > rather important. First, if we have a 27 bits TSC, with overflow every
> > 33ms at 4GHz, we assume the kernel will _never_ have an interrupt
> > latency longer than this for correct heartbeat behavior.
> 
> We do no such thing.
> 
> Guys, the heartbeat is a _separate_ thing from overflow handling.
> 
> You don't handle overflow by having a heartbeat that beats fifty times a 
> second just to insert events, just so that the TSC delta would always fit 
> in 27 bits. That would work, but be stupid. It would mean that you fill up 
> your event buffer with uninteresting crud just because nothing happens.
> 
> Yes, many people want to have a heartbeat (a "Mark" event) every once in a 
> while, but what I suggest is independent of heartbeats, even if it _could_ 
> be implemented that way. What I suggest is simply that when you insert an 
> event, you always read the full 64 bits of TSC (on x86 - others will do 
> other things), and then you insert the delta against the last one.
> 
> After all, you cannot read just 27 bits of the TSC anyway. You _have_ to 
> read the whole 64 bits, and then you subtract the pervious trace event TSC 
> (that you have in the per-CPU trace buffer header) from that. You now have 
> a delta value.
> 
> And if the delta doesn't fit in 27 bits, you generate a 59-bit TSC event!

Note: RFC v2 implements this.

-- Steve

> 
> None of this has _anything_ to do with interrupt latency. There is no 
> dependency on a heartbeat, or any dependency on always inserting a trace 
> event at least 30 times a second. There's no worry about conversions, and 
> these are all trivial single assembly instructions to do (or a couple, on 
> a 32-bit architecture that needs to do a sub/sbb pair and test two 
> different registers to see if the result fits in 27 bits).
> 
> The only issue is that if you insert trace events more seldom, you'll 
> always get the extra TSC event as well, inserted automatically in front of 
> the event you explicitly inserted. The tracer doesn't need to know.
--
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/