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 v1 0/8] perf: support resume and pause commands in stat and record modes
Date: Wed, 1 Apr 2020 16:01:06 +0200 [thread overview]
Message-ID: <20200401140106.GF2518490@krava> (raw)
In-Reply-To: <825a5132-b58d-c0b6-b050-5a6040386ec7@linux.intel.com>
On Fri, Mar 27, 2020 at 11:34:54AM +0300, Alexey Budankov wrote:
>
> The patch set implements handling of 'start paused', 'resume' and 'pause'
> external control commands which can be provided for stat and record modes
> of the tool from an external controlling process. 'start paused' command
> can be used to postpone enabling of events in the beginning of a monitoring
> session. 'resume' and 'pause' commands can be used to enable and disable
> events correspondingly any time after the start of the session.
>
> The 'start paused', resume and 'pause' external control commands can be
> used to focus measurement on specially selected time intervals of workload
> execution. Focused measurement reduces tool intrusion and influence on
> workload behavior, reduces distortion and amount of collected and stored
> data, mitigates data accuracy loss because measurement and data capturing
> happen only during intervals of interest.
>
> A controlling process can be a bash shell script [1], native executable or
> any other language program that can directly work with file descriptors,
> e.g. pipes [2], and spawn a process, specially the tool one.
>
> -D,--delay <val> option is extended with -1 value to skip events enabling
> in the beginning of a monitoring session ('start paused' command). --ctl-fd
> and --ctl-fd-ack command line options are introduced to provide the tool
> with a pair of file descriptors to listen to 'resume' and 'pause' commands
> and reply to an external controlling process on the completion of received
> commands processing.
>
> The tool reads two byte control command message from ctl-fd descriptor,
> handles the command and optionally replies two bytes acknowledgement message
> to fd-ack descriptor, if it is specified on the command line. 'resume' command
> is recognized as 'r' character message and 'pause' command is recognized as
> 'p' character message both received from ctl-fd descriptor. Completion message
> is 'a''\n' and sent to fd-ack descriptor.
>
> Bash script demonstrating simple use case follows:
>
> #!/bin/bash
>
> ctl_dir=/tmp/
>
> ctl_fifo=${ctl_dir}perf_ctl.fifo
> test -p ${ctl_fifo} && unlink ${ctl_fifo}
> mkfifo ${ctl_fifo} && exec {ctl_fd}<>${ctl_fifo}
>
> ctl_ack_fifo=${ctl_dir}perf_ctl_ack.fifo
> test -p ${ctl_ack_fifo} && unlink ${ctl_ack_fifo}
> mkfifo ${ctl_ack_fifo} && exec {ctl_fd_ack}<>${ctl_ack_fifo}
>
> perf stat -D -1 -e cpu-cycles -a -I 1000 \
> --ctl-fd ${ctl_fd} --ctl-fd-ack ${ctl_fd_ack} \
> -- sleep 40 &
hi,
is fifo the best choice? do you need it for plug perf in somewhere?
what's your use case for this?
fifos seem complicated because you need to create 2 of them, would
unix socket be better maybe? and do we really need that ack fd?
also you could pass just path and perf could create fifos from them
# perf stat --control-fifo /tmp/...
or to get really creazy, we could add option that would make perf
to listen on socket or whatever and we would control it via another
perf command ;-)
# perf stat --control ....
control socket: /tmp/xxx
# perf stat control -s /tmp/xxx disable
# perf stat control -s /tmp/xxx enable
but ATM I can't see too much use for this, so would be great to
know your usecase ;-)
thanks,
jirka
next prev parent reply other threads:[~2020-04-01 14:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 8:34 [PATCH v1 0/8] perf: support resume and pause commands in stat and record modes Alexey Budankov
2020-03-27 8:45 ` [PATCH v1 1/8] perf evlist: introduce control file descriptors Alexey Budankov
2020-03-27 8:46 ` [PATCH v1 2/8] perf evlist: implement control command handling functions Alexey Budankov
2020-04-02 14:17 ` Jiri Olsa
2020-04-02 15:20 ` Alexey Budankov
2020-03-27 8:47 ` [PATCH v1 3/8] perf stat: introduce control descriptors and --ctl-fd[-ack] options Alexey Budankov
2020-04-02 14:17 ` Jiri Olsa
2020-04-02 15:05 ` Alexey Budankov
2020-03-27 8:48 ` [PATCH v1 4/8] perf stat: implement resume and pause control commands handling Alexey Budankov
2020-04-02 14:17 ` Jiri Olsa
2020-04-02 15:06 ` Alexey Budankov
2020-03-27 8:49 ` [PATCH v1 5/8] perf docs: extend stat mode docs with info on --ctl-fd[-ack] options Alexey Budankov
2020-03-27 8:49 ` [PATCH v1 6/8] perf record: introduce control descriptors and " Alexey Budankov
2020-03-27 8:50 ` [PATCH v1 7/8] perf record: implement resume and pause control commands handling Alexey Budankov
2020-03-27 8:51 ` [PATCH v1 8/8] perf docs: extend record mode docs with info on --ctl-fd[-ack] options Alexey Budankov
2020-04-01 14:01 ` Jiri Olsa [this message]
2020-04-01 16:07 ` [PATCH v1 0/8] perf: support resume and pause commands in stat and record modes 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=20200401140106.GF2518490@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox