public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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