From: Peter Zijlstra <peterz@infradead.org>
To: Hideo AOKI <haoki@redhat.com>
Cc: mingo@elte.hu, mathieu.desnoyers@polymtl.ca,
Masami Hiramatsu <mhiramat@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Kernel marker has no performance impact on ia64.
Date: Tue, 03 Jun 2008 00:32:45 +0200 [thread overview]
Message-ID: <1212445965.6269.22.camel@lappy.programming.kicks-ass.net> (raw)
In-Reply-To: <48447052.3030300@redhat.com>
On Mon, 2008-06-02 at 18:12 -0400, Hideo AOKI wrote:
> Hello,
>
> I evaluated overhead of kernel marker using linux-2.6-sched-fixes
> git tree, which includes several markers for LTTng, using an ia64
> server.
>
> While the immediate trace mark feature isn't implemented on ia64,
> there is no major performance regression. So, I think that we
> don't have any issues to propose merging marker point patches
> into Linus's tree from the viewpoint of performance impact.
Performance is atm the least of the concerns regarding this work.
I'm still convinced markers are too ugly to live.
I also worry greatly about the fact that its too easy to expose too much
to user-space. There are no clear rules and the free form marker format
just begs for an inconsistent mess to arise.
IMHO the current free-form trace_mark() should be removed from the tree
- its great for ad-hoc debugging but its a disaster waiting to happen
for anything else. Anybody doing ad-hoc debugging can patch it in
themselves if needed.
Regular trace points can be custom made; this has the advantages that it
raises the implementation barrier and hopefully that encourages some
thought in the process. It also avoid the code from growing into
something that looks like someone had a long night of debugging.
next prev parent reply other threads:[~2008-06-02 22:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 22:12 Kernel marker has no performance impact on ia64 Hideo AOKI
2008-06-02 22:32 ` Peter Zijlstra [this message]
2008-06-02 23:21 ` Mathieu Desnoyers
2008-06-03 6:07 ` Takashi Nishiie
2008-06-04 4:58 ` Masami Hiramatsu
2008-06-04 23:26 ` Mathieu Desnoyers
2008-06-04 23:40 ` Masami Hiramatsu
2008-06-04 22:27 ` Peter Zijlstra
2008-06-04 23:22 ` Mathieu Desnoyers
2008-06-05 8:12 ` Peter Zijlstra
2008-06-05 14:28 ` Masami Hiramatsu
2008-06-12 14:04 ` Mathieu Desnoyers
2008-06-12 15:31 ` Masami Hiramatsu
2008-06-12 13:53 ` Mathieu Desnoyers
2008-06-12 14:27 ` Peter Zijlstra
2008-06-12 15:53 ` Frank Ch. Eigler
2008-06-12 16:16 ` Masami Hiramatsu
2008-06-12 16:43 ` Frank Ch. Eigler
2008-06-12 16:56 ` Peter Zijlstra
2008-06-12 22:10 ` Mathieu Desnoyers
2008-06-12 17:05 ` Masami Hiramatsu
2008-06-12 17:48 ` Frank Ch. Eigler
2008-06-12 19:34 ` Masami Hiramatsu
2008-06-13 4:19 ` Takashi Nishiie
2008-06-13 18:02 ` Masami Hiramatsu
2008-06-16 2:58 ` Takashi Nishiie
2008-06-12 16:53 ` Peter Zijlstra
2008-06-12 17:38 ` Frank Ch. Eigler
2008-06-13 11:01 ` Peter Zijlstra
2008-06-13 14:17 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1212445965.6269.22.camel@lappy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=haoki@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox