* Re: [tip:tracing/urgent] tracing: Allocate the ftrace event profile buffer dynamically [not found] <tip-31dcbc09033bd90190e90d943863d7ef9f39b93b@git.kernel.org> @ 2009-09-19 13:45 ` Steven Rostedt 2009-09-19 16:52 ` Ingo Molnar 0 siblings, 1 reply; 3+ messages in thread From: Steven Rostedt @ 2009-09-19 13:45 UTC (permalink / raw) To: linux-kernel, mingo, hpa, lizf, peterz, fweisbec, tglx, jbaron, mhiramat, mingo Cc: linux-tip-commits On Sat, 2009-09-19 at 07:58 +0000, tip-bot for Frederic Weisbecker wrote: > +/* > + * We can't use a size but a type in alloc_percpu() > + * So let's create a dummy type that matches the desired size > + */ > +typedef struct {char buf[FTRACE_MAX_PROFILE_SIZE];} profile_buf_t; > + > static int ftrace_profile_enable_event(struct ftrace_event_call *event) > { > + char *buf; > + int ret; > + > if (atomic_inc_return(&event->profile_count)) > return 0; > > - return event->profile_enable(); > + buf = (char *)alloc_percpu(profile_buf_t); > + if (!buf) > + return -ENOMEM; Ingo, Did you pull in the version that allocates a buffer for each event? I thought Frederic made just a global per cpu buffer that all events can use. The buffer is just a temporary storage that will be too big to put on the stack. -- Steve > + > + rcu_assign_pointer(event->profile_buf, buf); > + > + buf = (char *)alloc_percpu(profile_buf_t); > + if (!buf) { > + ret = -ENOMEM; > + goto fail_nmi; > + } > + > + rcu_assign_pointer(event->profile_buf_nmi, buf); > + > + ret = event->profile_enable(); > + if (!ret) > + return 0; > + > + kfree(event->profile_buf_nmi); > +fail_nmi: > + kfree(event->profile_buf); > + > + return ret; > } > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [tip:tracing/urgent] tracing: Allocate the ftrace event profile buffer dynamically 2009-09-19 13:45 ` [tip:tracing/urgent] tracing: Allocate the ftrace event profile buffer dynamically Steven Rostedt @ 2009-09-19 16:52 ` Ingo Molnar 0 siblings, 0 replies; 3+ messages in thread From: Ingo Molnar @ 2009-09-19 16:52 UTC (permalink / raw) To: Steven Rostedt Cc: linux-kernel, mingo, hpa, lizf, peterz, fweisbec, tglx, jbaron, mhiramat, linux-tip-commits * Steven Rostedt <rostedt@goodmis.org> wrote: > On Sat, 2009-09-19 at 07:58 +0000, tip-bot for Frederic Weisbecker > wrote: > > > +/* > > + * We can't use a size but a type in alloc_percpu() > > + * So let's create a dummy type that matches the desired size > > + */ > > +typedef struct {char buf[FTRACE_MAX_PROFILE_SIZE];} profile_buf_t; > > + > > static int ftrace_profile_enable_event(struct ftrace_event_call *event) > > { > > + char *buf; > > + int ret; > > + > > if (atomic_inc_return(&event->profile_count)) > > return 0; > > > > - return event->profile_enable(); > > + buf = (char *)alloc_percpu(profile_buf_t); > > + if (!buf) > > + return -ENOMEM; > > Ingo, > > Did you pull in the version that allocates a buffer for each event? I > thought Frederic made just a global per cpu buffer that all events can > use. The buffer is just a temporary storage that will be too big to > put on the stack. Yeah - i had v1 briefly - then pulled in the later (v3) one. Ingo ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <tip-20ab4425a77a1f34028cc6ce57053c22c184ba5f@git.kernel.org>]
* Re: [tip:tracing/urgent] tracing: Allocate the ftrace event profile buffer dynamically [not found] <tip-20ab4425a77a1f34028cc6ce57053c22c184ba5f@git.kernel.org> @ 2009-09-19 13:47 ` Steven Rostedt 0 siblings, 0 replies; 3+ messages in thread From: Steven Rostedt @ 2009-09-19 13:47 UTC (permalink / raw) To: linux-kernel, mingo, hpa, lizf, peterz, fweisbec, tglx, jbaron, mhiramat, mingo Cc: linux-tip-commits On Sat, 2009-09-19 at 10:06 +0000, tip-bot for Frederic Weisbecker wrote: > Commit-ID: 20ab4425a77a1f34028cc6ce57053c22c184ba5f > Gitweb: http://git.kernel.org/tip/20ab4425a77a1f34028cc6ce57053c22c184ba5f > Author: Frederic Weisbecker <fweisbec@gmail.com> > AuthorDate: Fri, 18 Sep 2009 06:10:28 +0200 > Committer: Frederic Weisbecker <fweisbec@gmail.com> > CommitDate: Fri, 18 Sep 2009 07:25:44 +0200 > > tracing: Allocate the ftrace event profile buffer dynamically > > Currently the trace event profile buffer is allocated in the stack. But > this may be too much for the stack, as the events can have large > statically defined field size and can also grow with dynamic arrays. > > Allocate two per cpu buffer for all profiled events. The first cpu > buffer is used to host every non-nmi context traces. It is protected > by disabling the interrupts while writing and committing the trace. > > The second buffer is reserved for nmi. So that there is no race between > them and the first buffer. > > The whole write/commit section is rcu protected because we release > these buffers while deactivating the last profiling trace event. > > v2: Move the buffers from trace_event to be global, as pointed by > Steven Rostedt. OK, now I'm confused ;-) This version looks like the correct one. -- Steve > > v3: Fix the syscall events to handle the profiling buffer races > by disabling interrupts, now that the buffers are globals. > > Suggested-by: Steven Rostedt <rostedt@goodmis.org> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> > Cc: Steven Rostedt <rostedt@goodmis.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Li Zefan <lizf@cn.fujitsu.com> > Cc: Jason Baron <jbaron@redhat.com> > Cc: Masami Hiramatsu <mhiramat@redhat.com> > Cc: Ingo Molnar <mingo@elte.hu> > ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-09-19 16:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <tip-31dcbc09033bd90190e90d943863d7ef9f39b93b@git.kernel.org>
2009-09-19 13:45 ` [tip:tracing/urgent] tracing: Allocate the ftrace event profile buffer dynamically Steven Rostedt
2009-09-19 16:52 ` Ingo Molnar
[not found] <tip-20ab4425a77a1f34028cc6ce57053c22c184ba5f@git.kernel.org>
2009-09-19 13:47 ` Steven Rostedt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox