[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0809271335001.10534@gandalf.stny.rr.com>
Date: Sat, 27 Sep 2008 13:38:15 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Linus Torvalds <torvalds@...ux-foundation.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
On Sat, 27 Sep 2008, Ingo Molnar wrote:
>
> 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.
Just a note. The current ring buffering system that I'm proposing keeps
its own time stamp counter (currently sched_clock) that will most likely
be updated later. I'm trying to keep this ring buffer system as dumb as
possible. It does not even implement the merge sort. That's up to the
tracer to handle. There's nothing stopping the trace from adding some
atomic counter to each event to help it sort.
So yes, the tracer can implement anything it wants on top of the ring
buffer ;-)
-- 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/
Powered by blists - more mailing lists