Messages in this thread | | | Date | Thu, 12 Jun 2008 13:48:34 -0400 | From | "Frank Ch. Eigler" <> | Subject | Re: Kernel marker has no performance impact on ia64. |
| |
Hi -
On Thu, Jun 12, 2008 at 01:05:52PM -0400, Masami Hiramatsu wrote: > [...] > >> "sched_switch(struct task_struct * next, struct task_struct * prev)":"next %p prev %p" > >> out of tree. Thus, you can use the printf-style format parser. > > > > That's an interesting idea, but errors in this table would themselves > > only be caught at C compilation time.
> Hmm, why would you think so? I think if we can't find corresponding > entry from the lookup table, it becomes an error.
Sure, but if the entry exists but is wrong, we'd emit C code that won't compile.
> [...] Even if you use trace_mark() markers, you have to post a > kernel patch which passes the prev->pid to the marking point and to > discuss it. for example, > DEFINE_TRACE(sched_switch, (int prev_pid, int next_pid), prev_pid, next_pid)
(If it were up to me, I would add the task pointers too, which debuginfo-less systemtap could ignore but other tracers may use.)
> But it might not so general, we have to discuss what parameters are > enough good for each marking point.
That's exactly what the "lttng instrumentation markers" threads from the recent past had started.
- FChE
| |