From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756289AbcECT4t (ORCPT ); Tue, 3 May 2016 15:56:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53201 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195AbcECT4s (ORCPT ); Tue, 3 May 2016 15:56:48 -0400 Date: Tue, 3 May 2016 15:56:44 -0400 From: Luiz Capitulino To: Clark Williams Cc: John Kacur , RT , LKML Subject: Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold Message-ID: <20160503155644.0aa34c34@redhat.com> In-Reply-To: <20160503125953.1987bedd@sluggy.hsv.redhat.com> References: <20160503125953.1987bedd@sluggy.hsv.redhat.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 May 2016 12:59:53 -0500 Clark Williams wrote: > John, > > This patch is against the devel/v0.98 branch. It turns off tracing in the tracemark() so that we don't lose information about what was going on when we hit the latency: > > > The current logic of using --tracemark and --notrace works for running > cyclictest with trace-cmd, but even if we are not doing any trace > manipulation in cyclictest, we still need to stop tracing when we hit a > breaktrace threshold (i.e. -b ). Does it solve the problem for you if you revert ba4dd1bf54 and start cyclictest with: # cyclictest [...] -bX Or with: # cyclictest [...] -bX --tracemark Also, how do I reproduce your issue? Are you doing tracing by hand? More comments below. > > Modify startup logic to hold open file descriptors for the tracemark file > *and* the tracing_on file. When we hit a threshold and call the tracemark() > function, write the marker to the trace buffers and then write a "0\n" to > the tracing_on file to turn off tracing, otherwise we lose the information > immediately prior to the point where we hit the latency. > > Signed-off-by: Clark Williams > --- > src/cyclictest/cyclictest.c | 32 ++++++++++++++++++++++++++------ > 1 file changed, 26 insertions(+), 6 deletions(-) > > diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c > index 902167010416..00e5f3d59a5b 100644 > --- a/src/cyclictest/cyclictest.c > +++ b/src/cyclictest/cyclictest.c > @@ -489,7 +489,12 @@ static void tracemark(char *fmt, ...) > va_start(ap, fmt); > len = vsnprintf(tracebuf, TRACEBUFSIZ, fmt, ap); > va_end(ap); > + > + /* write the tracemark message */ > write(tracemark_fd, tracebuf, len); > + > + /* now stop any trace */ > + write(trace_fd, "0\n", 2); > } We do tracing(0) when we hit the latency threshold, so I don't think this is necessary. However, have you checked that writing to tracing_on won't break trace-cmd when it exec()ed cyclictest? > > > @@ -535,13 +540,28 @@ static void open_tracemark_fd(void) > { > char path[MAX_PATH]; > > - if (tracemark_fd >= 0) > - return; > + /* > + * open the tracemark file if it's not already open > + */ > + if (tracemark_fd < 0) { > + sprintf(path, "%s/%s", fileprefix, "trace_marker"); > + tracemark_fd = open(path, O_WRONLY); > + if (tracemark_fd < 0) { > + warn("unable to open trace_marker file: %s\n", path); > + return; > + } > + } > > - sprintf(path, "%s/%s", fileprefix, "trace_marker"); > - tracemark_fd = open(path, O_WRONLY); > - if (tracemark_fd < 0) > - warn("unable to open trace_marker file: %s\n", path); > + /* > + * if we're not tracing and the tracing_on fd is not open, > + * open the tracing_on file so that we can stop the trace > + * if we hit a breaktrace threshold > + */ > + if (notrace && trace_fd < 0) { > + sprintf(path, "%s/%s", fileprefix, "tracing_on"); > + if ((trace_fd = open(path, O_WRONLY)) < 0) > + warn("unable to open tracing_on file: %s\n", path); > + } > } > > static void debugfs_prepare(void)