linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chun-Tse Shao <ctshao@google.com>
To: Ian Rogers <irogers@google.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	 Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	 Mark Rutland <mark.rutland@arm.com>,
	 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	 Adrian Hunter <adrian.hunter@intel.com>,
	Kan <kan.liang@linux.intel.com>,  Ze Gao <zegao2021@gmail.com>,
	Weilin Wang <weilin.wang@intel.com>,
	 linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 3/3] perf evsel: Find process with busy PMUs for EBUSY
Date: Fri, 1 Nov 2024 14:32:39 -0700	[thread overview]
Message-ID: <CAJpZYjXY4R=t1Wn2bkjEuThyCAC8_HTZ6JwtWPuQEs=weshbGQ@mail.gmail.com> (raw)
In-Reply-To: <CAP-5=fUZ_tXR7nqQjkNHgGbJ4dMLdOf0umR=y_hf9xJuCbfgfw@mail.gmail.com>

Thank you for your review! Here is the link to the v2 patch with
fixes: https://lore.kernel.org/all/20241101211757.824743-3-ctshao@google.com/

On Fri, Nov 1, 2024 at 9:14 AM Ian Rogers <irogers@google.com> wrote:
>
> On Thu, Oct 31, 2024 at 3:39 PM Chun-Tse Shao <ctshao@google.com> wrote:
> >
> > It parses fdinfo with PMU type, comparing with the event which failed to
> > open, and report the processes causing EBUSY error.
> >
> > ```
> > Testing cycles and intel_pt//
> > $ ./perf stat -e cycles &
> > [1] 55569
> > $ ./perf stat -e intel_pt// &
> > [2] 55683
> > $ ./perf stat -e intel_pt//
> > Error:
> > The PMU intel_pt counters are busy and in use by another process.
> > Possible processes:
> > 55683 ./perf stat -e intel_pt//
> > ```
> > Only perf with intel_pt was reported.
>
> I think this is a very nice addition. It is a shame there is a race
> with the existing process exiting, between the perf_event_open and the
> /proc scanning. A PMU may return EBUSY just because say perf list is
> probing features on the PMU so we probably have some extra retries for
> EBUSY too.
>
> > Signed-off-by: Chun-Tse Shao <ctshao@google.com>
> > ---
> >  tools/perf/util/evsel.c | 79 +++++++++++++++++++++++++++++------------
> >  1 file changed, 57 insertions(+), 22 deletions(-)
> >
> > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> > index 9a5b6a6f8d2e5..d2f7c19e023ec 100644
> > --- a/tools/perf/util/evsel.c
> > +++ b/tools/perf/util/evsel.c
> > @@ -3286,7 +3286,8 @@ static bool find_process(const char *name)
> >         return ret ? false : true;
> >  }
> >
> > -static int dump_perf_event_processes(char *msg, size_t size)
> > +static int dump_perf_event_processes(const struct perf_event_attr *failed_attr,
> > +                                    char *msg, size_t size)
> >  {
> >         DIR *proc_dir;
> >         struct dirent *proc_entry;
> > @@ -3327,29 +3328,61 @@ static int dump_perf_event_processes(char *msg, size_t size)
> >                                 continue;
> >                         /* Take care as readlink doesn't null terminate the string. */
> >                         if (!strncmp(path, "anon_inode:[perf_event]", link_size)) {
> > -                               int cmdline_fd;
> > -                               ssize_t cmdline_size;
> > -
> > -                               scnprintf(path, sizeof(path), "%s/cmdline", proc_entry->d_name);
> > -                               cmdline_fd = openat(dirfd(proc_dir), path, O_RDONLY);
> > -                               if (cmdline_fd == -1)
> > -                                       continue;
> > -                               cmdline_size = read(cmdline_fd, path, sizeof(path) - 1);
> > -                               close(cmdline_fd);
> > -                               if (cmdline_size < 0)
> > +                               int fdinfo_fd;
> > +                               ssize_t fdinfo_size;
> > +                               char *line;
> > +                               u32 perf_event_type = PERF_TYPE_MAX;
>
> PERF_TYPE_MAX is beyond the pre-defined perf PMU types at 6 but PMU
> drivers loaded by the kernel may use this number - I think task-clock
> may use this PMU type number but it shouldn't return EBUSY. Anyway, I
> think -1 would be a better marker to use here and in the corresponding
> check below.
>
> Thanks,
> Ian

In this case I am using UINT32_MAX instead to avoid the overflow. If
kernel would still use this value, I can make it u64 or add a variable
`found` instead.

>
> > +
> > +                               /* Let's check the PMU type reserved by this process */
> > +                               scnprintf(path, sizeof(path), "%s/fdinfo/%s",
> > +                                         proc_entry->d_name, fd_entry->d_name);
> > +                               fdinfo_fd = openat(dirfd(proc_dir), path, O_RDONLY);
> > +                               fdinfo_size = read(fdinfo_fd, path, sizeof(path) - 1);
> > +                               if (fdinfo_size < 0)
> >                                         continue;
> > -                               path[cmdline_size] = '\0';
> > -                               for (ssize_t i = 0; i < cmdline_size; i++) {
> > -                                       if (path[i] == '\0')
> > -                                               path[i] = ' ';
> > +                               path[fdinfo_size] = '\0';
> > +
> > +                               line = strtok(path, "\n");
> > +                               while (line != NULL) {
> > +                                       if (sscanf(line,
> > +                                                  "perf_event-attr.type:\t%u",
> > +                                                  &perf_event_type) == 1)
> > +                                               break;
> > +                                       line = strtok(NULL, "\n");
> >                                 }
> >
> > -                               if (printed == 0)
> > -                                       printed += scnprintf(msg, size, "Possible processes:\n");
> > -
> > -                               printed += scnprintf(msg + printed, size - printed,
> > -                                               "%s %s\n", proc_entry->d_name, path);
> > -                               break;
> > +                               /* Report the process which reserves the conflicted PMU. */
> > +                               /* If fdinfo does not contain PMU type, report it too. */
> > +                               if (perf_event_type == failed_attr->type ||
> > +                                   perf_event_type == PERF_TYPE_MAX) {
> > +                                       int cmdline_fd;
> > +                                       ssize_t cmdline_size;
> > +
> > +                                       scnprintf(path, sizeof(path),
> > +                                                 "%s/cmdline",
> > +                                                 proc_entry->d_name);
> > +                                       cmdline_fd = openat(dirfd(proc_dir), path, O_RDONLY);
> > +                                       if (cmdline_fd == -1)
> > +                                               continue;
> > +                                       cmdline_size = read(cmdline_fd, path, sizeof(path) - 1);
> > +                                       close(cmdline_fd);
> > +                                       if (cmdline_size < 0)
> > +                                               continue;
> > +                                       path[cmdline_size] = '\0';
> > +                                       for (ssize_t i = 0; i < cmdline_size; i++) {
> > +                                               if (path[i] == '\0')
> > +                                                       path[i] = ' ';
> > +                                       }
> > +
> > +                                       if (printed == 0)
> > +                                               printed += scnprintf(
> > +                                                       msg, size,
> > +                                                       "Possible processes:\n");
> > +
> > +                                       printed += scnprintf(msg + printed, size - printed,
> > +                                                       "%s %s\n", proc_entry->d_name, path);
> > +                                       break;
> > +                               }
> >                         }
> >                 }
> >                 closedir(fd_dir);
> > @@ -3458,7 +3491,9 @@ int evsel__open_strerror(struct evsel *evsel, struct target *target,
> >                         msg, size,
> >                         "The PMU %s counters are busy and in use by another process.\n",
> >                         evsel->pmu ? evsel->pmu->name : "");
> > -               return printed + dump_perf_event_processes(msg + printed, size - printed);
> > +               return printed + dump_perf_event_processes(&evsel->core.attr,
> > +                                                          msg + printed,
> > +                                                          size - printed);
> >                 break;
> >         case EINVAL:
> >                 if (evsel->core.attr.sample_type & PERF_SAMPLE_CODE_PAGE_SIZE && perf_missing_features.code_page_size)
> > --
> > 2.47.0.163.g1226f6d8fa-goog
> >

      reply	other threads:[~2024-11-01 21:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-31 22:39 [PATCH 1/3] perf evsel: Improve the evsel__open_strerror for EBUSY Chun-Tse Shao
2024-10-31 22:39 ` [PATCH 2/3] perf: Reveal PMU type in fdinfo Chun-Tse Shao
2024-11-01 16:02   ` Ian Rogers
2024-11-01 21:24     ` Chun-Tse Shao
2024-11-05 12:24   ` Peter Zijlstra
2024-11-05 15:15     ` Ian Rogers
2024-10-31 22:39 ` [PATCH 3/3] perf evsel: Find process with busy PMUs for EBUSY Chun-Tse Shao
2024-11-01 16:14   ` Ian Rogers
2024-11-01 21:32     ` Chun-Tse Shao [this message]

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='CAJpZYjXY4R=t1Wn2bkjEuThyCAC8_HTZ6JwtWPuQEs=weshbGQ@mail.gmail.com' \
    --to=ctshao@google.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=weilin.wang@intel.com \
    --cc=zegao2021@gmail.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).