From: Oleg Nesterov <oleg@redhat.com>
To: "zhangwei(Jovi)" <jovi.zhangwei@huawei.com>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: ftrace multibuffer && rcu (Was: tracing/uprobes: Support ftrace_event_file base multibuffer)
Date: Fri, 14 Jun 2013 18:04:56 +0200 [thread overview]
Message-ID: <20130614160456.GA14726@redhat.com> (raw)
In-Reply-To: <20130614144442.GA1943@redhat.com>
On 06/14, Oleg Nesterov wrote:
>
> > -probe_event_enable(struct trace_uprobe *tu, int flag, filter_func_t filter)
> > +probe_event_enable(struct trace_uprobe *tu, struct ftrace_event_file *file,
> > + filter_func_t filter)
> > {
> > + int enabled = 0;
> > int ret = 0;
> >
> > + mutex_lock(&uprobe_enable_lock);
>
> Do we really need this? Can't we really on mutex_event hold by the caller?
Looks like, kprobes do not need probe_enable_lock too.
Steven, Masami, I just looked at this new multibuffer code. Not sure
I really understand it, but it seems that ftrace_event_file should
help its users.
Lets look at enable_trace_probe(). Firstly, "ftrace_event_file **files"
and the add/remove code doesn't look very nice, list_head looks more
convenient.
But the main problem is, synchronize_sched() is slow and it is called
under the global event_mutex.
So perhaps something like below (untested) makes sense? With this patch
we can trivially convert trace_kprobe.c to use list_add/del/each_rcu.
What do you think?
Oleg.
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -294,8 +294,32 @@ struct ftrace_event_file {
*/
unsigned long flags;
atomic_t sm_ref; /* soft-mode reference counter */
+ atomic_t refcnt;
+ struct rcu_head rcu;
};
+struct event_file_link {
+ struct ftrace_event_file *file;
+ struct list_head list;
+ struct rcu_head rcu;
+};
+
+extern void rcu_free_event_file_link(struct rcu_head *rcu);
+
+static inline struct event_file_link *
+alloc_event_file_link(struct ftrace_event_file *file)
+{
+ struct event_file_link *link = kmalloc(sizeof(*link), GFP_KERNEL);
+ if (link)
+ link->file = file;
+ return link;
+}
+
+static inline void free_event_file_link(struct event_file_link *link)
+{
+ call_rcu(&link->rcu, rcu_free_event_file_link);
+}
+
#define __TRACE_EVENT_FLAGS(name, value) \
static int __init trace_init_flags_##name(void) \
{ \
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -1542,6 +1542,7 @@ trace_create_new_event(struct ftrace_event_call *call,
file->event_call = call;
file->tr = tr;
atomic_set(&file->sm_ref, 0);
+ atomic_set(&file->refcnt, 1);
list_add(&file->list, &tr->events);
return file;
@@ -2182,6 +2183,17 @@ __trace_early_add_events(struct trace_array *tr)
}
}
+static void put_event_file(struct ftrace_event_file *file)
+{
+ if (atomic_dec_and_test(&file->refcnt))
+ kmem_cache_free(file_cachep, file);
+}
+
+static void delayed_put_event_file(struct rcu_head *rcu)
+{
+ put_event_file(container_of(rcu, struct ftrace_event_file, rcu));
+}
+
/* Remove the event directory structure for a trace directory. */
static void
__trace_remove_event_dirs(struct trace_array *tr)
@@ -2192,10 +2204,18 @@ __trace_remove_event_dirs(struct trace_array *tr)
list_del(&file->list);
debugfs_remove_recursive(file->dir);
remove_subsystem(file->system);
- kmem_cache_free(file_cachep, file);
+ call_rcu(&file->rcu, delayed_put_event_file);
}
}
+void rcu_free_event_file_link(struct rcu_head *rcu)
+{
+ struct event_file_link *link =
+ container_of(rcu, struct event_file_link, rcu);
+ put_event_file(link->file);
+ kfree(link);
+}
+
static void
__add_event_to_tracers(struct ftrace_event_call *call,
struct ftrace_module_file_ops *file_ops)
next prev parent reply other threads:[~2013-06-14 16:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-14 1:44 [PATCH] tracing/uprobes: Support ftrace_event_file base multibuffer zhangwei(Jovi)
2013-06-14 13:21 ` Masami Hiramatsu
2013-06-14 13:51 ` Oleg Nesterov
2013-06-14 14:09 ` Oleg Nesterov
2013-06-14 15:31 ` Steven Rostedt
2013-06-14 16:21 ` Paul E. McKenney
2013-06-14 16:33 ` Steven Rostedt
2013-06-14 17:25 ` Paul E. McKenney
2013-06-17 2:54 ` Masami Hiramatsu
2013-06-17 12:33 ` Steven Rostedt
2013-06-18 1:31 ` Masami Hiramatsu
2013-06-18 2:02 ` Steven Rostedt
2013-06-14 14:44 ` Oleg Nesterov
2013-06-14 16:04 ` Oleg Nesterov [this message]
2013-06-14 16:18 ` ftrace multibuffer && rcu (Was: tracing/uprobes: Support ftrace_event_file base multibuffer) Oleg Nesterov
2013-06-14 16:26 ` Steven Rostedt
2013-06-14 17:02 ` Oleg Nesterov
2013-06-20 16:43 ` [PATCH] tracing/uprobes: Support ftrace_event_file base multibuffer Oleg Nesterov
2013-06-21 8:17 ` zhangwei(Jovi)
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=20130614160456.GA14726@redhat.com \
--to=oleg@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jovi.zhangwei@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.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