From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Clark Williams <williams@redhat.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Song Liu <songliubraving@fb.com>, Wang Nan <wangnan0@huawei.com>
Subject: Re: [PATCH 7/7] perf record: Introduce --switch-output-event
Date: Tue, 28 Apr 2020 15:22:57 +0200 [thread overview]
Message-ID: <20200428132257.GH1476763@krava> (raw)
In-Reply-To: <20200428121601.GB2245@kernel.org>
On Tue, Apr 28, 2020 at 09:16:01AM -0300, Arnaldo Carvalho de Melo wrote:
SNIP
> > > + pr_err("Couldn't create side band evlist.\n.");
> > > + goto out_child;
> > > + }
> > > }
> > >
> > > if (evlist__add_bpf_sb_event(rec->sb_evlist, &session->header.env)) {
> >
> > it's getting bigger, I wonder we should put all the sb_* setup in
> > separated functions like sb_start/sb_stop
>
> Well, the rec->thread_id = pthread_self(); part is just for reusing a
> 'perf record' specific mechanism, what to do when the event appears in
> the side band thread ring buffer, the evlist__set_cb() also is related
> to that, moving thread_id to evlist seems too much at this time.
hum, I meant record specific static functions sb_start/sb_stop,
not inside evlist.. just to have it separated
>
> > > @@ -2179,10 +2199,19 @@ static int switch_output_setup(struct record *rec)
> > > };
> > > unsigned long val;
> > >
> > > + /*
> > > + * If we're using --switch-output-events, then we imply its
> > > + * --switch-output=signal, as we'll send a SIGUSR2 from the side band
> > > + * thread to its parent.
> > > + */
> > > + if (rec->sb_evlist != NULL)
> > > + goto do_signal;
> > > +
> > > if (!s->set)
> > > return 0;
>
> > hum, it looks like this jump is not necessay and can be avoided
> > by some bool checks.. could we add some bool when --switch-output-event
> > is used, so we don't depend on wether rec->sb_evlist was allocated for
> > whatever reason?
>
> If rec->sb_evlist is NULL, then there was no --switch-output-event
> passed... The only advantage in adding the complexity below would be if
> we had rec->switch_output_event_set which would clarify that sb_evlist
> is not used only for --switch-output-event, to make things clearer.
>
> And this still leaves us with the jump, otherwise we would have to test
> it twice, right?
still I like the idea of checking bool twice then adding jumps
>
> I think I'll separate the patch adding OPT_CALLBACK_SET(), then fold the
> switch_output_event_set addition to builtin-record, ok?
ok, or set the bool directly in the callback, both works for me ;-)
thanks,
jirka
next prev parent reply other threads:[~2020-04-28 13:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 21:19 [RFC PATCHSET] Implement --switch-output-events Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 1/7] perf record: Move sb_evlist to 'struct record' Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 2/7] perf top: Move sb_evlist to 'struct perf_top' Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 3/7] perf bpf: Decouple creating the evlist from adding the SB event Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 4/7] " Arnaldo Carvalho de Melo
2020-04-28 9:48 ` Jiri Olsa
2020-04-28 17:21 ` Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 5/7] perf parse-events: Add parse_events_option() variant that creates evlist Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 6/7] perf evlist: Allow reusing the side band thread for more purposes Arnaldo Carvalho de Melo
2020-04-27 21:19 ` [PATCH 7/7] perf record: Introduce --switch-output-event Arnaldo Carvalho de Melo
2020-04-28 9:48 ` Jiri Olsa
2020-04-28 12:16 ` Arnaldo Carvalho de Melo
2020-04-28 13:22 ` Jiri Olsa [this message]
2020-04-28 18:05 ` Arnaldo Carvalho de Melo
2020-04-29 8:18 ` Jiri Olsa
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=20200428132257.GH1476763@krava \
--to=jolsa@redhat.com \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=arnaldo.melo@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
--cc=wangnan0@huawei.com \
--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.