All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Song Liu <songliubraving@fb.com>, Song Liu <song@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>,
	"acme@redhat.com" <acme@redhat.com>,
	"namhyung@kernel.org" <namhyung@kernel.org>,
	"jolsa@kernel.org" <jolsa@kernel.org>
Subject: Re: [PATCH v5 5/5] perf-stat: introduce bpf_counter_ops->disable()
Date: Mon, 3 May 2021 12:25:22 -0300	[thread overview]
Message-ID: <YJAV4vBUFr6sz5tM@kernel.org> (raw)
In-Reply-To: <YJAEKfvUXFPCik5+@krava>

Em Mon, May 03, 2021 at 04:09:45PM +0200, Jiri Olsa escreveu:
> On Thu, Apr 29, 2021 at 10:40:01PM +0000, Song Liu wrote:
> 
> SNIP
> 
> > >>>>> #include "../perf.h"
> > >>>>> @@ -421,6 +422,9 @@ static void __evlist__disable(struct evlist *evlist, char *evsel_name)
> > >>>>> 	if (affinity__setup(&affinity) < 0)
> > >>>>> 		return;

> > >>>>> +	evlist__for_each_entry(evlist, pos)
> > >>>>> +		bpf_counter__disable(pos);

> > >>>> I was wondering why you don't check evsel__is_bpf like
> > >>>> for the enable case.. and realized that we don't skip
> > >>>> bpf evsels in __evlist__enable and __evlist__disable
> > >>>> like we do in read_affinity_counters

> > >>>> so I guess there's extra affinity setup and bunch of
> > >>>> wrong ioctls being called?

> > >>> We actually didn't do wrong ioctls because the following check:

> > >>>      if (... || !pos->core.fd)
> > >>>               continue;

> > >>> in __evlist__enable and __evlist__disable. That we don't allocate 
> > >>> core.fd for is_bpf events. 

> > >>> It is probably good to be more safe with an extra check of 
> > >>> evsel__is_bpf(). But it is not required with current code. 

> > >> hum, but it will do all the affinity setup no? for no reason,
> > >> if there's no non-bpb event

> > > Yes, it will do the affinity setup. Let me see how to get something
> > > like all_counters_use_bpf here (or within builtin-stat.c).

> > Would something like the following work? It is not clean (skipping some 
> > useful logic in __evlist__[enable|disable]). But it seems to work in the
> > tests.

> sorry for late reply, but I can't no longer apply this:
 
> 	patching file tools/perf/builtin-stat.c
> 	Hunk #1 FAILED at 572.
> 	Hunk #2 FAILED at 581.
> 	2 out of 2 hunks FAILED -- saving rejects to file tools/perf/builtin-stat.c.rej
> 	patching file tools/perf/util/evlist.c
> 	Hunk #1 FAILED at 425.
> 	1 out of 1 hunk FAILED -- saving rejects to file tools/perf/util/evlist.c.rej
 
> ah, I see the patchset got already merged.. not sure why I'm doing review then ;-)

Hey, sometimes this can happen, sorry. Song, please submit on top of
what is upstream.

- Arnaldo

  reply	other threads:[~2021-05-03 15:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-25 21:43 [PATCH v5 0/5] perf util: bpf perf improvements Song Liu
2021-04-25 21:43 ` [PATCH v5 1/5] perf util: move bpf_perf definitions to a libperf header Song Liu
2021-04-25 21:43 ` [PATCH v5 2/5] perf bpf: check perf_attr_map is compatible with the perf binary Song Liu
2021-04-25 21:43 ` [PATCH v5 3/5] perf-stat: introduce config stat.bpf-counter-events Song Liu
2021-04-25 21:43 ` [PATCH v5 4/5] perf-stat: introduce ':b' modifier Song Liu
2021-04-25 21:43 ` [PATCH v5 5/5] perf-stat: introduce bpf_counter_ops->disable() Song Liu
2021-04-26 21:27   ` Jiri Olsa
2021-04-26 22:18     ` Song Liu
2021-04-27 12:33       ` Jiri Olsa
2021-04-27 19:30         ` Song Liu
2021-04-29 22:40           ` Song Liu
2021-05-03 14:09             ` Jiri Olsa
2021-05-03 15:25               ` Arnaldo Carvalho de Melo [this message]
2021-04-27 19:27   ` Arnaldo Carvalho de Melo
2021-04-27 19:42     ` 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=YJAV4vBUFr6sz5tM@kernel.org \
    --to=acme@kernel.org \
    --cc=Kernel-team@fb.com \
    --cc=acme@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=song@kernel.org \
    --cc=songliubraving@fb.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.