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]

Message-ID: <20080927171640.GA1990@elte.hu>
Date:	Sat, 27 Sep 2008 19:16:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Martin Bligh <mbligh@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Martin Bligh <mbligh@...igh.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

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 26 Sep 2008, Ingo Molnar wrote:
> > 
> > i do not understand this argument of yours. (really)
> > 
> > 1) is your point that we might lock up?
> 
> Have you at all followed the discussion about the people who asked for 
> cross-CPU ordering? They wanted not timestamps at all, but global 
> atomic counter updates. Which is very reasonable, if timestamps don't 
> work (and jiffies certainly doesn't, especially in a NOHZ 
> environment).
> 
> IOW, my whole argument is that what tracers want is _not_ the same 
> thing as what "sched_clock()" wants.

ah, i see what you mean. I think that's an orthogonal property.

Well, it's important in some cases, not that important in other cases.

Historically we've been flip-flopping on that issue in ftrace, whether 
it should be coherent by default or not. We had at least three of four 
variations of global synchronization. (one was an atomic generation 
counter, another variant a global lock)

Eventually people noticed the overhead and asked for it to be faster.

If all you do is to trace high-freq events on all CPUs and you are _not_ 
interested in the precise interactions, the overhead of global 
synchronization can hurt a lot.

In any case, SMP coherency of trace events is an independent property of 
the tracer, and preferably something that can be turned on/off.

	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/