From: Masami Hiramatsu <mhiramat@redhat.com>
To: Takashi Nishiie <t-nishiie@np.css.fujitsu.com>
Cc: "'Frank Ch. Eigler'" <fche@redhat.com>,
"'Peter Zijlstra'" <peterz@infradead.org>,
"'Mathieu Desnoyers'" <mathieu.desnoyers@polymtl.ca>,
"'Hideo AOKI'" <haoki@redhat.com>,
mingo@elte.hu, linux-kernel@vger.kernel.org,
"'Steven Rostedt'" <rostedt@goodmis.org>
Subject: Re: Kernel marker has no performance impact on ia64.
Date: Fri, 13 Jun 2008 14:02:16 -0400 [thread overview]
Message-ID: <4852B628.8040906@redhat.com> (raw)
In-Reply-To: <004101c8cd0c$aa093190$fe1b94b0$@css.fujitsu.com>
Hi Takashi,
Thank you for comment.
Takashi Nishiie wrote:
> Hi,Hiramatsu
>
> Hiramatsu wrote:
>
>> I think if someone changes the trace point in the kernel,
>> Module.markers is also changed.
>>
>> ex.)
>> DEFINE_TRACE(sched_switch, (struct task_struct * next, struct task_struct
> * prev),
>> next, prev);
>>
>> if someone changes above to below,
>>
>> DEFINE_TRACE(sched_switch, (int prev_pid, int next_pid), prev_pid,
> next_pid);
>> Module.markers also change like
>>
>> sched_switch vmlinux (struct task_struct * next, struct task_struct *
> prev)
>> to
>>
>> sched_switch vmlinux (int prev_pid, int next_pid)
>>
>> In this case, the below entry never matches to new Module.markers.
>>
>> "sched_switch(struct task_struct * next, struct task_struct * prev)":"next
> %p prev %p"
>> Thus, we can find an error.
>> However, of cause, we should take care of the task_struct changes.
>
> The one expected of markers with SystemTap and LTTng is only
> different the foundation of this discussion.
>
> SystemTap:
> Because the output format is basically defined with user script in
> systemtap script, "format information" is unnecessary. It can do
> nothing but guess from "format information" in present markers though
> the type of the argument is indispensable for SystemTap on the other
> hand. If the type of an accurate argument is understood, correct
> processing can be executed. Moreover, being able to refer to the
> member of the structure if the argument is a pointer of the structure
> becomes possible, and it is convenient.
It's not so easy for systemtap... for example, if a marker pass 'char *',
how can we do it? it might have to record as a string, or might have to
record as a pointer. Obviously, printf-style information includes a kind of
'semantic' information. So, I think the 'lookup table' is good.
> LTTng:
> Because the output format is not originally defined in LTTng, "format
> information" is indispensable.
Sure, however, LTTng can have original "format information" itself.
> I think that I only have to add the item that shows the type of an
> accurate argument if the format of "Module.markers" is changed.
I think those 'semantic' type information (which informs you what
is this value and how this value should be recorded) should be
defined by each tracer, because what information they want to
extract from arguments are strongly depends on their use cases.
Actually, that requires tracers to pay maintenance costs, but
it's not so big if the "regular" marking point is enough stable.
Regards,
>
> Thank you,
>
> --
> Takashi Nishiie
>
>
>
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com
next prev parent reply other threads:[~2008-06-13 18:04 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
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 [this message]
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=4852B628.8040906@redhat.com \
--to=mhiramat@redhat.com \
--cc=fche@redhat.com \
--cc=haoki@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=t-nishiie@np.css.fujitsu.com \
/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