From: Jiri Olsa <jolsa@redhat.com>
To: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Andi Kleen <ak@linux.intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/9] perf stat: factor out event handling loop into a function
Date: Thu, 21 May 2020 13:48:59 +0200 [thread overview]
Message-ID: <20200521114859.GU157452@krava> (raw)
In-Reply-To: <a03c1c18-6e87-692f-87a5-bd4124d56bc9@linux.intel.com>
On Wed, May 20, 2020 at 06:17:40PM +0300, Alexey Budankov wrote:
SNIP
> >> @@ -675,16 +708,9 @@ static int __run_perf_stat(int argc, const char **argv, int run_idx)
> >> perf_evlist__start_workload(evsel_list);
> >> enable_counters();
> >>
> >> - if (interval || timeout) {
> >> - while (!waitpid(child_pid, &status, WNOHANG)) {
> >> - nanosleep(&ts, NULL);
> >> - if (timeout)
> >> - break;
> >> - process_interval();
> >> - if (interval_count && !(--times))
> >> - break;
> >> - }
> >> - }
> >> + if (interval || timeout)
> >> + handle_events(child_pid, &stat_config);
> >> +
> >> if (child_pid != -1) {
> >> if (timeout)
> >> kill(child_pid, SIGTERM);
> >> @@ -701,18 +727,7 @@ static int __run_perf_stat(int argc, const char **argv, int run_idx)
> >> psignal(WTERMSIG(status), argv[0]);
> >> } else {
> >> enable_counters();
> >> - while (!done) {
> >> - nanosleep(&ts, NULL);
> >> - if (!is_target_alive(&target, evsel_list->core.threads))
> >> - break;
> >> - if (timeout)
> >> - break;
> >> - if (interval) {
> >> - process_interval();
> >> - if (interval_count && !(--times))
> >> - break;
> >> - }
> >> - }
> >> + handle_events(-1, &stat_config);
> >
> > this makes me worried.. I'm not sure if it's good idea
> > to squash these 2 looops into one, because they are already
> > complex as they are.. and one of you following patches is
> > making it even more complex
>
> Loops bodies are mostly identical. The only difference is in events
> they wait for and API used for that. Adding of more events will
> complicate further. The code is duplicated, thus needs refactoring.
> If the following patch complicates lets organize the patch it into
> several smaller functions.
yea, that might help
jirka
>
> >
> > wouldn't it be better if you just add single call into
> > each of them.. that would poll on your fd and process the
> > commands if needed?
>
> That's of course possible, but doesn't manage existing complexity
> at the first place - __run_perf_stat().
>
> Let's still have handle_events() as a general dispatcher and implement
> handlers for different events as separate functions?
>
> ~Alexey
>
next prev parent reply other threads:[~2020-05-21 11:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 7:53 [PATCH v3 0/9] perf: support enable and disable commands in stat and record modes Alexey Budankov
2020-05-13 7:59 ` [PATCH v3 1/9] perf evlist: introduce control file descriptors Alexey Budankov
2020-05-20 12:38 ` Jiri Olsa
2020-05-20 14:46 ` Alexey Budankov
2020-05-13 8:00 ` [PATCH v3 2/9] perf evlist: implement control command handling functions Alexey Budankov
2020-05-20 12:38 ` Jiri Olsa
2020-05-20 14:56 ` Alexey Budankov
2020-05-13 8:00 ` [PATCH v3 3/9] perf stat: factor out event handling loop into a function Alexey Budankov
2020-05-20 12:38 ` Jiri Olsa
2020-05-20 15:17 ` Alexey Budankov
2020-05-21 11:48 ` Jiri Olsa [this message]
2020-05-13 8:01 ` [PATCH v3 4/9] perf stat: extend -D,--delay option with -1 value Alexey Budankov
2020-05-13 8:02 ` [PATCH v3 5/9] perf stat: implement control commands handling Alexey Budankov
2020-05-13 8:03 ` [PATCH v3 6/9] perf stat: introduce --ctl-fd[-ack] options Alexey Budankov
2020-05-20 12:38 ` Jiri Olsa
2020-05-20 15:05 ` Alexey Budankov
2020-05-13 8:03 ` [PATCH v3 7/9] perf record: extend -D,--delay option with -1 value Alexey Budankov
2020-05-13 8:04 ` [PATCH v3 8/9] perf record: implement control commands handling Alexey Budankov
2020-05-20 12:38 ` Jiri Olsa
2020-05-20 18:06 ` Alexey Budankov
2020-05-13 8:05 ` [PATCH v3 9/9] perf record: introduce --ctl-fd[-ack] options Alexey Budankov
2020-05-20 12:38 ` Jiri Olsa
2020-05-20 15:21 ` Alexey Budankov
2020-05-18 8:08 ` [PATCH v3 0/9] perf: support enable and disable commands in stat and record modes Alexey Budankov
2020-05-20 10:55 ` Jiri Olsa
-- strict thread matches above, loose matches on Subject: below --
2020-05-08 10:43 Alexey Budankov
2020-05-08 10:48 ` [PATCH v3 3/9] perf stat: factor out event handling loop into a function Alexey Budankov
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=20200521114859.GU157452@krava \
--to=jolsa@redhat.com \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@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.