All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Clark Williams <williams@redhat.com>
Cc: John Kacur <jkacur@redhat.com>,
	RT <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold
Date: Tue, 3 May 2016 15:56:44 -0400	[thread overview]
Message-ID: <20160503155644.0aa34c34@redhat.com> (raw)
In-Reply-To: <20160503125953.1987bedd@sluggy.hsv.redhat.com>

On Tue, 3 May 2016 12:59:53 -0500
Clark Williams <williams@redhat.com> 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 <n>).

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 <williams@redhat.com>
> ---
>  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)

  reply	other threads:[~2016-05-03 19:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-03 17:59 [PATCH] cyclictest: stop any tracing after hitting a breaktrace threshold Clark Williams
2016-05-03 19:56 ` Luiz Capitulino [this message]
2016-05-03 20:28   ` Clark Williams
2016-05-04 13:20     ` Luiz Capitulino
2016-05-04 13:49       ` John Kacur

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=20160503155644.0aa34c34@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=williams@redhat.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.