All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Mike Galbraith <efault@gmx.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Paul Mackerras <paulus@samba.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Gabriel Munteanu <eduard.munteanu@linux360.ro>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>
Subject: Re: [PATCH] perfcounters: Support for ftrace event records sampling
Date: Fri, 07 Aug 2009 22:28:51 +0200	[thread overview]
Message-ID: <1249676931.17467.7.camel@twins> (raw)
In-Reply-To: <20090807202105.GB4999@nowhere>

On Fri, 2009-08-07 at 22:21 +0200, Frederic Weisbecker wrote:
> On Fri, Aug 07, 2009 at 10:09:07PM +0200, Peter Zijlstra wrote:
> > On Fri, 2009-08-07 at 12:38 +0200, Peter Zijlstra wrote:
> > > > +static void ftrace_profile_##call(proto)                             \
> > > > +{                                                                    \
> > > > +     struct ftrace_data_offsets_##call __maybe_unused __data_offsets;\
> > > > +     struct ftrace_event_call *event_call = &event_##call;           \
> > > > +     extern void perf_tpcounter_event(int, u64, u64, void *, int);   \
> > > > +     struct ftrace_raw_##call *entry;                                \
> > > > +     u64 __addr = 0, __count = 1;                                    \
> > > > +     unsigned long irq_flags;                                        \
> > > > +     int __entry_size;                                               \
> > > > +     int __data_size;                                                \
> > > > +     int pc;                                                         \
> > > > +                                                                     \
> > > > +     local_save_flags(irq_flags);                                    \
> > > > +     pc = preempt_count();                                           \
> > > > +                                                                     \
> > > > +     __data_size = ftrace_get_offsets_##call(&__data_offsets, args); \
> > > > +     __entry_size = __data_size + sizeof(*entry);                    \
> > > > +                                                                     \
> > > > +     do {                                                            \
> > > > +             char raw_data[__entry_size];                            \
> > > > +             struct trace_entry *ent;                                \
> > > > +                                                                     \
> > > > +             entry = (struct ftrace_raw_##call *)raw_data;           \
> > > > +             ent = &entry->ent;                                      \
> > > > +             tracing_generic_entry_update(ent, irq_flags, pc);       \
> > > > +             ent->type = event_call->id;                             \
> > > > +                                                                     \
> > > > +             tstruct                                                 \
> > > > +                                                                     \
> > > > +             { assign; }                                             \
> > > > +                                                                     \
> > > > +             perf_tpcounter_event(event_call->id, __addr, __count, entry,\
> > > > +                          __entry_size);                             \
> > > > +     } while (0);                                                    \
> > > > +                                                                     \
> > > > +}
> > > 
> > > ok, so the one concern I have here is that the data needs to fit on the
> > > stack. What if someone puts a large string in the data?
> > 
> > Also, how NMI safe is all that?
> 
> 
> Everything is allocated in the stack. It's NMI safe AFAICS, am I missing
> something?

I've no idea what all those trace calls do, I was hoping you would and
say, sure, no problem ;-)

  reply	other threads:[~2009-08-07 20:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 23:25 [PATCH] perfcounters: Support for ftrace event records sampling Frederic Weisbecker
2009-08-07  7:33 ` [tip:perfcounters/tracing] perf_counter: " tip-bot for Frederic Weisbecker
2009-08-07 10:11   ` Ingo Molnar
2009-08-07 20:22     ` Frederic Weisbecker
2009-08-07 10:37 ` [PATCH] perfcounters: " Peter Zijlstra
2009-08-07 10:58   ` Ingo Molnar
2009-08-07 20:09   ` Peter Zijlstra
2009-08-07 20:21     ` Frederic Weisbecker
2009-08-07 20:28       ` Peter Zijlstra [this message]
2009-08-07 20:36         ` Frederic Weisbecker
2009-08-07 20:26   ` Frederic Weisbecker
2009-08-07 15:54 ` Peter Zijlstra
2009-08-07 16:18   ` [tip:perfcounters/core] perfcounters: Support for ftrace event records sampling, fix modules tip-bot for Peter Zijlstra

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=1249676931.17467.7.camel@twins \
    --to=peterz@infradead.org \
    --cc=acme@redhat.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=penberg@cs.helsinki.fi \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.