From: Li Zefan <lizf@cn.fujitsu.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Zhaolei <zhaolei@cn.fujitsu.com>,
Tom Zanussi <tzanussi@gmail.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC][PATCH 1/2] tracing/events: provide string with undefined size support
Date: Thu, 16 Apr 2009 09:13:25 +0800 [thread overview]
Message-ID: <49E68635.8050404@cn.fujitsu.com> (raw)
In-Reply-To: <1239838050-8567-1-git-send-email-fweisbec@gmail.com>
Frederic Weisbecker wrote:
> Impact: less memory usage for tracing
>
> This patch provides the support for dynamic size strings on
> event tracing.
>
blktrace TRACE_EVENTs need this too. :)
> The key concept is to use a structure with an ending char array field of
> undefined size and use such ability to allocate the minimal size on the ring
> buffer to make the entry fit inside as opposite to a fixed length strings with
> upper bound.
>
> This patch provides two new macros:
>
> -__ending_string(name)
>
> This one declares the string to the structure inside TP_STRUCT__entry.
> Only the name is needed.
> Two constraints: only one __ending_string() per TRACE_EVENT can be added and
> it must be the last field to be declared. Hence the __ending prefix.
>
> - open_string_assign(call, dst, src)
>
> This one does the copy inside TP__fast_assign() of the source
> string to the destination. The name of the tracepoint (call) must be provided
> for now. Hopefully I will find a solution to avoid it later.
>
> Two constraint: can be used only once and always on the beginning because
> it needs to manage the ring buffer reservation by itself. Hence the open prefix.
>
> How does it works?
>
I'll let you know if I meet any problem when using this in blktrace
TRACE_EVENTs.
> A new has_ending_string field has been added to struct ftrace_event_call and is
> false by default.
> Once a TRACE_EVENT uses an __ending_string field, it is set to 1.
>
> Until now, the ring buffer reservation was done in ftrace_raw_event_##call().
> It is still the case if we don't have an __ending_string() field. If we have one,
> open_string_assign() will manage it itself to allocate the appropriate size,
> depending of the size of the string to be copied for each trace.
>
> The choice between the usual static allocation and the new dynamic one depends
> on the "has_ending_string" value.
>
> It also support filtering because these strings behave essentially
> like usual fixed length string.
>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> ---
> include/linux/ftrace_event.h | 1 +
> include/trace/ftrace.h | 62 ++++++++++++++++++++++++++++++++++++-----
> 2 files changed, 55 insertions(+), 8 deletions(-)
...
> +/*
> + * If we have and ending undefined string size, then the size of
> + * the entry is dynamic. In such case we override the ring buffer
> + * reservation to manage it ourselves with our dynamic string size.
> + */
> +#undef open_string_assign
> +#define open_string_assign(call, dst, src) \
> + event = trace_current_buffer_lock_reserve( \
> + event_##call.id, \
> + sizeof(struct ftrace_raw_##call) + strlen(src) + 1, \
> + irq_flags, pc); \
> + if (!event) \
> + return; \
> + entry = ring_buffer_event_data(event); \
small nits, below is better since we have only one assignment:
entry = ring_buffer_event_data(event);
> + strcpy(entry->dst, src);
> +
> #undef TRACE_EVENT
> #define TRACE_EVENT(call, proto, args, tstruct, assign, print) \
> _TRACE_PROFILE(call, PARAMS(proto), PARAMS(args)) \
> @@ -418,20 +461,23 @@ static struct ftrace_event_call event_##call; \
> static void ftrace_raw_event_##call(proto) \
> { \
> struct ftrace_event_call *call = &event_##call; \
> - struct ring_buffer_event *event; \
> - struct ftrace_raw_##call *entry; \
> + struct ring_buffer_event *event = NULL; \
> + struct ftrace_raw_##call *entry = NULL; \
> unsigned long irq_flags; \
> int pc; \
> \
> local_save_flags(irq_flags); \
> pc = preempt_count(); \
> \
> - event = trace_current_buffer_lock_reserve(event_##call.id, \
> - sizeof(struct ftrace_raw_##call), \
> - irq_flags, pc); \
> - if (!event) \
> - return; \
> - entry = ring_buffer_event_data(event); \
> + if (!call->has_ending_string) { \
> + event = trace_current_buffer_lock_reserve( \
> + event_##call.id, \
> + sizeof(struct ftrace_raw_##call), \
> + irq_flags, pc); \
> + if (!event) \
> + return; \
> + entry = ring_buffer_event_data(event); \
ditoo
> + } \
> \
> assign; \
> \
next prev parent reply other threads:[~2009-04-16 1:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-15 23:27 [RFC][PATCH 1/2] tracing/events: provide string with undefined size support Frederic Weisbecker
2009-04-15 23:27 ` [RFC][PATCH 2/2] tracing/lock: provide lock_acquired event support for dynamic size string Frederic Weisbecker
2009-04-16 1:13 ` Li Zefan [this message]
2009-04-16 7:42 ` [RFC][PATCH 1/2] tracing/events: provide string with undefined size support Frederic Weisbecker
2009-04-16 7:54 ` Li Zefan
2009-04-16 16:19 ` Frederic Weisbecker
2009-04-16 1:33 ` Steven Rostedt
2009-04-16 7:35 ` Frederic Weisbecker
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=49E68635.8050404@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=a.p.zijlstra@chello.nl \
--cc=fweisbec@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
--cc=zhaolei@cn.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 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.