Message ID | 1454957515-29258-1-git-send-email-hollis_blanchard@mentor.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Hollis Blanchard <hollis_blanchard@mentor.com> writes: > Previously, trace record files (created by st_set_trace_file_enabled(true)) > were created by the simple backend at initialization time, even if no events > were actually enabled. > > As a consequence, the working directory would become littered with trace-PID > files just by enabling the simple backend at configure time, even when no > -trace options were used. > > --- > I've been using this to avoid creation of empty trace record files. I haven't > done any scientific performance studies, but an extra function > call/conditional/return when recording every trace event doesn't seem to have > any noticeable effect. > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> > --- > trace/simple.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/trace/simple.c b/trace/simple.c > index 3fdcc82..67ccc3c 100644 > --- a/trace/simple.c > +++ b/trace/simple.c > @@ -209,6 +209,8 @@ int trace_record_start(TraceBufferRecord *rec, TraceEventID event, size_t datasi > uint64_t event_u64 = event; > uint64_t timestamp_ns = get_clock(); > > + st_set_trace_file_enabled(true); > + > do { > old_idx = g_atomic_int_get(&trace_idx); > smp_rmb(); > @@ -320,6 +322,7 @@ void st_set_trace_file_enabled(bool enable) > */ > void st_set_trace_file(const char *file) > { > + /* Tracing will be re-enabled when the next event is written. */ > st_set_trace_file_enabled(false); > > g_free(trace_file_name); > @@ -330,8 +333,6 @@ void st_set_trace_file(const char *file) > } else { > trace_file_name = g_strdup_printf("%s", file); > } > - > - st_set_trace_file_enabled(true); > } This fixes the "make check" bug I reported: http://lists.nongnu.org/archive/html/qemu-devel/2016-02/msg01811.html because by not enabling the file it doesn't attempt to flush it before the test has started. However as it is a side-effect of the patch there may be a better solution. However have a: Tested-by: Alex Bennée <alex.bennee@linaro.org> -- Alex Bennée
On Mon, Feb 08, 2016 at 10:51:55AM -0800, Hollis Blanchard wrote: > Previously, trace record files (created by st_set_trace_file_enabled(true)) > were created by the simple backend at initialization time, even if no events > were actually enabled. > > As a consequence, the working directory would become littered with trace-PID > files just by enabling the simple backend at configure time, even when no > -trace options were used. > > --- > I've been using this to avoid creation of empty trace record files. I haven't > done any scientific performance studies, but an extra function > call/conditional/return when recording every trace event doesn't seem to have > any noticeable effect. > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> > --- > trace/simple.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/trace/simple.c b/trace/simple.c > index 3fdcc82..67ccc3c 100644 > --- a/trace/simple.c > +++ b/trace/simple.c > @@ -209,6 +209,8 @@ int trace_record_start(TraceBufferRecord *rec, TraceEventID event, size_t datasi > uint64_t event_u64 = event; > uint64_t timestamp_ns = get_clock(); > > + st_set_trace_file_enabled(true); trace_record_start() can be called from multiple threads. st_set_trace_file_enabled() is not thread-safe. One way to solve this is to use a read memory barrier to fetch trace_fp. If it's NULL then acquire trace_lock and recheck (in case another thread has modified it since). Now continue with the rest of st_set_trace_file_enabled() to open the file. If multiple threads pile up they will just wait for trace_lock until the first thread has completed opening the file. Or you could use try_lock instead and return -EBUSY to drop those events similar to the -ENOSPC error case in trace_record_start(). Stefan
On Mon, Feb 08, 2016 at 10:51:55AM -0800, Hollis Blanchard wrote: > Previously, trace record files (created by st_set_trace_file_enabled(true)) > were created by the simple backend at initialization time, even if no events > were actually enabled. > > As a consequence, the working directory would become littered with trace-PID > files just by enabling the simple backend at configure time, even when no > -trace options were used. > > --- > I've been using this to avoid creation of empty trace record files. I haven't > done any scientific performance studies, but an extra function > call/conditional/return when recording every trace event doesn't seem to have > any noticeable effect. > > Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> > --- > trace/simple.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) By the way, thanks for the patch. I didn't see it because my maintainership scripts use my stefanha@redhat.com email account that is listed in ./MAINTAINERS. Stefan
diff --git a/trace/simple.c b/trace/simple.c index 3fdcc82..67ccc3c 100644 --- a/trace/simple.c +++ b/trace/simple.c @@ -209,6 +209,8 @@ int trace_record_start(TraceBufferRecord *rec, TraceEventID event, size_t datasi uint64_t event_u64 = event; uint64_t timestamp_ns = get_clock(); + st_set_trace_file_enabled(true); + do { old_idx = g_atomic_int_get(&trace_idx); smp_rmb(); @@ -320,6 +322,7 @@ void st_set_trace_file_enabled(bool enable) */ void st_set_trace_file(const char *file) { + /* Tracing will be re-enabled when the next event is written. */ st_set_trace_file_enabled(false); g_free(trace_file_name); @@ -330,8 +333,6 @@ void st_set_trace_file(const char *file) } else { trace_file_name = g_strdup_printf("%s", file); } - - st_set_trace_file_enabled(true); } void st_print_trace_file_status(FILE *stream, int (*stream_printf)(FILE *stream, const char *fmt, ...))
Previously, trace record files (created by st_set_trace_file_enabled(true)) were created by the simple backend at initialization time, even if no events were actually enabled. As a consequence, the working directory would become littered with trace-PID files just by enabling the simple backend at configure time, even when no -trace options were used. --- I've been using this to avoid creation of empty trace record files. I haven't done any scientific performance studies, but an extra function call/conditional/return when recording every trace event doesn't seem to have any noticeable effect. Signed-off-by: Hollis Blanchard <hollis_blanchard@mentor.com> --- trace/simple.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)