[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080417185158.GA26603@elte.hu>
Date: Thu, 17 Apr 2008 20:51:58 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Pekka Enberg <penberg@...helsinki.fi>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [v2.6.26] what's brewing in x86.git for v2.6.26
* Andrew Morton <akpm@...ux-foundation.org> wrote:
> afaik the sysprof-vs-oprofile issue still hasn't been settled. Maybe
> it's no longer a relevant question with the new code - I just don't
> know. Everything went all quiet and then this stuff happened.
i dont think there's any big issue here. Sysprof is a time and stack
system-wide tracer/profiler, oprofile profiles CPU events - deep
stacktracing is an afterthought there. And how do you set up oprofile to
do precise time events?
with sysprof you can do:
cd /sys/kernel/debug/tracing
echo sysprof > current_tracer
cat trace_pipe
and you'll see the trace events go by, live. The user-space bits of
sysprof have been ported over to ftrace/sysprof already and it's a
really nice tool that shows a deep stack-trace based hierarchical
"vertical" profile instead of the usual finegrained profile.
It certainly helps that the author of the tracer plugin (Soeren
Sandmann) is the author of the userspace app too - so there's a rather
well-working feedback loop here ;-)
With oprofile all these things are rather indirect, the API is more
complex, it forces per-CPU buffers, etc. etc. I think for
instrumentation the driving force must be usability, and sysprof/ftrace
is hands down more usable - to me at least.
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/
Powered by blists - more mailing lists