linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Naveen N Rao" <naveen@kernel.org>
To: "Kajol Jain" <kjain@linux.ibm.com>, <acme@kernel.org>
Cc: <maddy@linux.ibm.com>, <atrajeev@linux.vnet.ibm.com>,
	<disgoel@linux.ibm.com>, <linuxppc-dev@lists.ozlabs.org>,
	<linux-perf-users@vger.kernel.org>, <irogers@google.com>,
	<namhyung@kernel.org>, <naveen.n.rao@linux.vnet.ibm.com>,
	"Disha Goel" <disgoel@linux.vnet.ibm.com>
Subject: Re: [PATCH] perf test: Skip perf bench breakpoint run if no breakpoints available
Date: Wed, 23 Aug 2023 16:28:41 +0530	[thread overview]
Message-ID: <CUZVDJPWI4GL.NVVOJTWE6U5S@naverao1-tp> (raw)
In-Reply-To: <20230823075103.190565-1-kjain@linux.ibm.com>

Hi Kajol,

On Wed Aug 23, 2023 at 1:21 PM IST, Kajol Jain wrote:
> Based on commit 7d54a4acd8c1 ("perf test: Skip watchpoint
> tests if no watchpoints available"), hardware breakpoints
> are not available for power9 platform and because of that
> perf bench breakpoint run fails on power9 platform.
> Add code to check for the return value of perf_event_open()
> in breakpoint run and skip the perf bench breakpoint run,
> if hardware breakpoints are not available.
>
> Result on power9 system before patch changes:
> [command]# perf bench breakpoint thread
> perf_event_open: No such device
>
> Result on power9 system after patch changes:
> [command]# ./perf bench breakpoint thread
> Skipping perf bench breakpoint thread: No hardware support
>
> Reported-by: Disha Goel <disgoel@linux.vnet.ibm.com>
> Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
> ---
>  tools/perf/bench/breakpoint.c | 24 +++++++++++++++++++++---
>  1 file changed, 21 insertions(+), 3 deletions(-)

Thanks for fixing this to not report an error. A minor nit below, but 
otherwise:
Acked-by: Naveen N Rao <naveen@kernel.org>

>
> diff --git a/tools/perf/bench/breakpoint.c b/tools/perf/bench/breakpoint.c
> index 41385f89ffc7..dfd18f5db97d 100644
> --- a/tools/perf/bench/breakpoint.c
> +++ b/tools/perf/bench/breakpoint.c
> @@ -47,6 +47,7 @@ struct breakpoint {
>  static int breakpoint_setup(void *addr)
>  {
>  	struct perf_event_attr attr = { .size = 0, };
> +	int fd;
>  
>  	attr.type = PERF_TYPE_BREAKPOINT;
>  	attr.size = sizeof(attr);
> @@ -56,7 +57,12 @@ static int breakpoint_setup(void *addr)
>  	attr.bp_addr = (unsigned long)addr;
>  	attr.bp_type = HW_BREAKPOINT_RW;
>  	attr.bp_len = HW_BREAKPOINT_LEN_1;
> -	return syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0);
> +	fd = syscall(SYS_perf_event_open, &attr, 0, -1, -1, 0);
> +
> +	if (fd < 0)
> +		fd = -errno;
> +
> +	return fd;
>  }
>  
>  static void *passive_thread(void *arg)
> @@ -122,8 +128,14 @@ int bench_breakpoint_thread(int argc, const char **argv)
>  
>  	for (i = 0; i < thread_params.nbreakpoints; i++) {
>  		breakpoints[i].fd = breakpoint_setup(&breakpoints[i].watched);
> -		if (breakpoints[i].fd == -1)
> +
> +		if (breakpoints[i].fd < 0) {
> +			if (breakpoints[i].fd == -ENODEV) {
> +				printf("Skipping perf bench breakpoint thread: No hardware support\n");
> +				return 0;

Should we instead do 'exit(0)' here to stop further benchmarks? Perhaps:
  err(EXIT_SUCCESS, "Skipping perf bench breakpoint thread: No hardware support");

EXIT_SUCCESS looks weird, but should help document that this is not an 
error.

> +			}
>  			exit((perror("perf_event_open"), EXIT_FAILURE));
> +		}
>  	}
>  	gettimeofday(&start, NULL);
>  	for (i = 0; i < thread_params.nparallel; i++) {
> @@ -196,8 +208,14 @@ int bench_breakpoint_enable(int argc, const char **argv)
>  		exit(EXIT_FAILURE);
>  	}
>  	fd = breakpoint_setup(&watched);
> -	if (fd == -1)
> +
> +	if (fd < 0) {
> +		if (fd == -ENODEV) {
> +			printf("Skipping perf bench breakpoint enable: No hardware support\n");
> +			return 0;

Here too.

- Naveen

> +		}
>  		exit((perror("perf_event_open"), EXIT_FAILURE));
> +	}
>  	nthreads = enable_params.npassive + enable_params.nactive;
>  	threads = calloc(nthreads, sizeof(threads[0]));
>  	if (!threads)


  reply	other threads:[~2023-08-23 11:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-23  7:51 [PATCH] perf test: Skip perf bench breakpoint run if no breakpoints available Kajol Jain
2023-08-23 10:58 ` Naveen N Rao [this message]
2023-08-29 19:03   ` Ian Rogers
2023-08-23 11:40 ` Arnaldo Carvalho de Melo

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=CUZVDJPWI4GL.NVVOJTWE6U5S@naverao1-tp \
    --to=naveen@kernel.org \
    --cc=acme@kernel.org \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=disgoel@linux.ibm.com \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=irogers@google.com \
    --cc=kjain@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=namhyung@kernel.org \
    --cc=naveen.n.rao@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;
as well as URLs for NNTP newsgroup(s).