From: Adrian Hunter <adrian.hunter@intel.com>
To: Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/5] perf: Add ioctl to emit sideband events
Date: Tue, 18 Apr 2023 16:36:11 +0300 [thread overview]
Message-ID: <d7d6cbc8-1f5f-d0f4-6656-f0cc8ab3a118@intel.com> (raw)
In-Reply-To: <89733d35-0b71-615f-4fb8-55183585c67a@intel.com>
On 18/04/23 09:18, Adrian Hunter wrote:
> On 17/04/23 14:02, Peter Zijlstra wrote:
>> On Fri, Apr 14, 2023 at 11:22:55AM +0300, Adrian Hunter wrote:
>>> Hi
>>>
>>> Here is a stab at adding an ioctl for sideband events.
>>>
>>> This is to overcome races when reading the same information
>>> from /proc.
>>
>> What races? Are you talking about reading old state in /proc the kernel
>> delivering a sideband event for the new state, and then you writing the
>> old state out?
>>
>> Surely that's something perf tool can fix without kernel changes?
>
> Yes, and it was a bit of a brain fart not to realise that.
>
> There may still be corner cases, where different kinds of events are
> interdependent, perhaps NAMESPACES events vs MMAP events could
> have ordering issues.
>
> Putting that aside, the ioctl may be quicker than reading from
> /proc. I could get some numbers and see what people think.
>
Here's a result with a quick hack to use the ioctl but without
handling the buffer becoming full (hence the -m4M)
# ps -e | wc -l
1171
# perf.old stat -- perf.old record -o old.data --namespaces -a true
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.095 MB old.data (100 samples) ]
Performance counter stats for 'perf.old record -o old.data --namespaces -a true':
498.15 msec task-clock # 0.987 CPUs utilized
126 context-switches # 252.935 /sec
64 cpu-migrations # 128.475 /sec
4396 page-faults # 8.825 K/sec
1927096347 cycles # 3.868 GHz
4563059399 instructions # 2.37 insn per cycle
914232559 branches # 1.835 G/sec
6618052 branch-misses # 0.72% of all branches
9633787105 slots # 19.339 G/sec
4394300990 topdown-retiring # 38.8% Retiring
3693815286 topdown-bad-spec # 32.6% Bad Speculation
1692356927 topdown-fe-bound # 14.9% Frontend Bound
1544151518 topdown-be-bound # 13.6% Backend Bound
0.504636742 seconds time elapsed
0.158237000 seconds user
0.340625000 seconds sys
# perf.old stat -- perf.new record -o new.data -m4M --namespaces -a true
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.095 MB new.data (103 samples) ]
Performance counter stats for 'perf.new record -o new.data -m4M --namespaces -a true':
386.61 msec task-clock # 0.988 CPUs utilized
100 context-switches # 258.658 /sec
65 cpu-migrations # 168.128 /sec
4935 page-faults # 12.765 K/sec
1495905137 cycles # 3.869 GHz
3647660473 instructions # 2.44 insn per cycle
735822370 branches # 1.903 G/sec
5765668 branch-misses # 0.78% of all branches
7477722620 slots # 19.342 G/sec
3415835954 topdown-retiring # 39.5% Retiring
2748625759 topdown-bad-spec # 31.8% Bad Speculation
1221594670 topdown-fe-bound # 14.1% Frontend Bound
1256150733 topdown-be-bound # 14.5% Backend Bound
0.391472763 seconds time elapsed
0.141207000 seconds user
0.246277000 seconds sys
# ls -lh old.data
-rw------- 1 root root 1.2M Apr 18 13:19 old.data
# ls -lh new.data
-rw------- 1 root root 1.2M Apr 18 13:19 new.data
#
next prev parent reply other threads:[~2023-04-18 13:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-14 8:22 [PATCH RFC 0/5] perf: Add ioctl to emit sideband events Adrian Hunter
2023-04-14 8:22 ` [PATCH RFC 1/5] " Adrian Hunter
2023-04-17 10:57 ` Peter Zijlstra
2023-04-18 6:29 ` Adrian Hunter
2023-04-14 8:22 ` [PATCH RFC 2/5] perf: Add fork to the sideband ioctl Adrian Hunter
2023-04-14 8:22 ` [PATCH RFC 3/5] perf: Add namespaces " Adrian Hunter
2023-04-14 8:22 ` [PATCH RFC 4/5] perf: Add comm " Adrian Hunter
2023-04-14 8:23 ` [PATCH RFC 5/5] perf: Add mmap " Adrian Hunter
2023-04-17 11:02 ` [PATCH RFC 0/5] perf: Add ioctl to emit sideband events Peter Zijlstra
2023-04-17 16:37 ` Ian Rogers
2023-04-18 7:03 ` Adrian Hunter
2023-04-18 6:18 ` Adrian Hunter
2023-04-18 13:36 ` Adrian Hunter [this message]
2023-04-18 15:51 ` Ian Rogers
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=d7d6cbc8-1f5f-d0f4-6656-f0cc8ab3a118@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).