All of lore.kernel.org
 help / color / mirror / Atom feed
From: Song Liu <songliubraving@fb.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Networking <netdev@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	Kernel Team <Kernel-team@fb.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	"jolsa@kernel.org" <jolsa@kernel.org>,
	"namhyung@kernel.org" <namhyung@kernel.org>
Subject: Re: [PATCH v4 perf,bpf 14/15] perf: introduce side band thread
Date: Tue, 5 Mar 2019 20:37:17 +0000	[thread overview]
Message-ID: <3CC5A7C5-C417-46D4-8B09-4BD1A2CE3A96@fb.com> (raw)
In-Reply-To: <20190305110330.GA16022@krava>



> On Mar 5, 2019, at 3:03 AM, Jiri Olsa <jolsa@redhat.com> wrote:
> 
> On Mon, Mar 04, 2019 at 09:40:07PM +0000, Song Liu wrote:
>> 
>> 
>>> On Feb 27, 2019, at 5:21 AM, Jiri Olsa <jolsa@redhat.com> wrote:
>>> 
>>> On Mon, Feb 25, 2019 at 04:20:18PM -0800, Song Liu wrote:
>>> 
>>> SNIP
>>> 
>>>> diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
>>>> index 8c902276d4b4..61b87c8111e6 100644
>>>> --- a/tools/perf/util/evlist.c
>>>> +++ b/tools/perf/util/evlist.c
>>>> @@ -19,6 +19,7 @@
>>>> #include "debug.h"
>>>> #include "units.h"
>>>> #include "asm/bug.h"
>>>> +#include "bpf-event.h"
>>>> #include <signal.h>
>>>> #include <unistd.h>
>>>> 
>>>> @@ -1841,3 +1842,102 @@ struct perf_evsel *perf_evlist__reset_weak_group(struct perf_evlist *evsel_list,
>>>> 	}
>>>> 	return leader;
>>>> }
>>>> +
>>>> +static struct perf_evlist *sb_evlist;
>>>> +pthread_t poll_thread;
>>> 
>>> so some of the things are static and some like poll_args
>>> you alloced on the stack.. I dont like this interface,
>>> could we come up with something generic? perhaps
>>> encapsulated in perf_evlist, like:
>>> 
>>> struct perf_evlist {
>>> 	...
>>> 	struct {
>>> 		pthread_t	th;
>>> 		int		state;
>>> 	} thread;
>>> };
>>> 
>>> typedef int (perf_evlist__thread_cb_t)(perf_evlist, union perf_event *event,....)
>>> 
>>> perf_evlist__start_thread(perf_evlist, perf_evlist__thread_cb_t cb);
>>> perf_evlist__stop_thread(perf_evlist);
>>> 
>>> 
>>> jirka
>> 
>> More questions on this proposal: 
>> 
>> IIUC, this approach creates one perf_evlist and one thread for each side band
>> event (only bpf for now, more afterwards). Each of these perf_evlists will 
>> create its own ring buffer. 
>> 
>> On the other hand, current patch allows different events to share the thread, 
>> the perf_evlist, and the ring buffer. 
> 
> you can have those events in single evlist no?
> 
>> 
>> If my understanding is correct, current patch would be more efficient down the 
>> road? Did I miss some downsides of current patch?
> 
> I'd just like something configurable and with single handle
> not scattered around the code, so it's easy to add new callback 
> 
> jirka

To make adding callbacks easy, we need to register callback per perf_evsel, so 
multiple side band events could share the perf_evlist. It will be something like:

typedef int (perf_evsel__sb_cb_t)(union perf_event *event, void *data);

struct perf_evsel {
	...
	struct {
		perf_evsel__sb_cb_t *cb;
		void *data;
	} side_band;
};

perf_evlist__add_sb_event(struct perf_evlist *evlist, 
			  struct perf_event_attr *attr, 
			  perf_evsel__sb_cb_t cb, 
			  void *data);
perf_evlist__start_sb_evlist(struct perf_evlist *evlist);
perf_evlist__stop_sb_evlist(struct perf_evlist *evlist);


Does this look like a good approach?

Thanks,
Song


  reply	other threads:[~2019-03-05 20:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26  0:20 [PATCH v4 perf,bpf 00/15] perf annotation of BPF programs Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 01/15] perf, bpf: consider events with attr.bpf_event as side-band events Song Liu
2019-03-09 19:46   ` [tip:perf/urgent] perf, bpf: Consider " tip-bot for Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 02/15] bpf: libbpf: introduce bpf_program__get_prog_info_linear() Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 03/15] bpf: bpftool: use bpf_program__get_prog_info_linear() in prog.c:do_dump() Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 04/15] perf, bpf: synthesize bpf events with bpf_program__get_prog_info_linear() Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 05/15] perf: change prototype of perf_event__synthesize_bpf_events() Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 06/15] perf, bpf: save bpf_prog_info in a rbtree in perf_env Song Liu
2019-02-27 13:21   ` Jiri Olsa
2019-02-27 17:38     ` Song Liu
2019-02-27 13:21   ` Jiri Olsa
2019-02-27 13:21   ` Jiri Olsa
2019-02-26  0:20 ` [PATCH v4 perf,bpf 07/15] perf, bpf: save bpf_prog_info information as headers to perf.data Song Liu
2019-02-27 13:21   ` Jiri Olsa
2019-02-27 17:28     ` Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 08/15] perf, bpf: save btf in a rbtree in perf_env Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 09/15] perf, bpf: save btf information as headers to perf.data Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 10/15] perf-top: add option --no-bpf-event Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 11/15] perf: add -lopcodes to feature-libbfd Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 12/15] perf, bpf: enable annotation of bpf program Song Liu
2019-02-27 13:21   ` Jiri Olsa
2019-02-27 13:22   ` Jiri Olsa
2019-02-26  0:20 ` [PATCH v4 perf,bpf 13/15] perf, bpf: process PERF_BPF_EVENT_PROG_LOAD for annotation Song Liu
2019-02-26  0:20 ` [PATCH v4 perf,bpf 14/15] perf: introduce side band thread Song Liu
2019-02-27 13:21   ` Jiri Olsa
2019-02-27 17:52     ` Song Liu
2019-03-04 13:52       ` Jiri Olsa
2019-03-04 19:49         ` Song Liu
2019-03-04 20:41           ` Jiri Olsa
2019-03-04 20:44             ` Song Liu
2019-03-04 21:40     ` Song Liu
2019-03-05 11:03       ` Jiri Olsa
2019-03-05 20:37         ` Song Liu [this message]
2019-02-26  0:20 ` [PATCH v4 perf,bpf 15/15] perf, bpf: save information about short living bpf programs Song Liu
2019-02-27 13:21   ` Jiri Olsa
2019-02-27 17:42     ` Song Liu

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=3CC5A7C5-C417-46D4-8B09-4BD1A2CE3A96@fb.com \
    --to=songliubraving@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=acme@redhat.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    /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.