From: Ian Rogers <irogers@google.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
James Clark <james.clark@arm.com>,
Kees Cook <keescook@chromium.org>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Riccardo Mancini <rickyman7@gmail.com>,
German Gomez <german.gomez@arm.com>,
Colin Ian King <colin.king@intel.com>,
Song Liu <songliubraving@fb.com>,
Dave Marchevsky <davemarchevsky@fb.com>,
Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
Alexey Bayduraev <alexey.v.bayduraev@linux.intel.com>,
Leo Yan <leo.yan@linaro.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Stephane Eranian <eranian@google.com>, Ian Rogers <irogers@google.com>
Subject: [PATCH v2 0/6] Corrections to cpu map event encoding
Date: Tue, 14 Jun 2022 07:33:47 -0700 [thread overview]
Message-ID: <20220614143353.1559597-1-irogers@google.com> (raw)
A mask encoding of a cpu map is laid out as:
u16 nr
u16 long_size
unsigned long mask[];
However, the mask may be 8-byte aligned meaning there is a 4-byte pad
after long_size. This means 32-bit and 64-bit builds see the mask as
being at different offsets. On top of this the structure is in the byte
data[] encoded as:
u16 type
char data[]
This means the mask's struct isn't the required 4 or 8 byte aligned, but
is offset by 2. Consequently the long reads and writes are causing
undefined behavior as the alignment is broken.
These changes do minor clean up with const, visibility of functions
and using the constant time max function. It then adds 32 and 64-bit
mask encoding variants, packed to match current alignment. Taking the
address of a packed struct leads to unaligned data, so function
arguments are altered to be passed the packed struct. To compact the
mask encoding further and drop the padding, the 4-byte variant is
preferred. Finally a new range encoding is added, that reduces the
size of the common case of a range of CPUs to a single u64.
On a 72 CPU (hyperthread) machine the original encoding of all CPUs is:
0x9a98 [0x28]: event: 74
.
. ... raw event: size 40 bytes
. 0000: 4a 00 00 00 00 00 28 00 01 00 02 00 08 00 00 00 J.....(.........
. 0010: 00 00 ff ff ff ff ff ff ff ff ff 00 00 00 00 00 ................
. 0020: 00 00 00 00 00 00 00 00 ........
0 0 0x9a98 [0x28]: PERF_RECORD_CPU_MAP
Using the 4-byte encoding it is:
0x9a98@pipe [0x20]: event: 74
.
. ... raw event: size 32 bytes
. 0000: 4a 00 00 00 00 00 20 00 01 00 03 00 04 00 ff ff J..... .........
. 0010: ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 ................
0 0 0x9a98 [0x20]: PERF_RECORD_CPU_MAP
Finally, with the range encoding it is:
0x9ab8@pipe [0x10]: event: 74
.
. ... raw event: size 16 bytes
. 0000: 4a 00 00 00 00 00 10 00 02 00 00 00 00 00 47 00 J.............G.
0 0 0x9ab8 [0x10]: PERF_RECORD_CPU_MAP
v2. Fixes a bug in the size computation of the update header
introduced by the last patch (Add range data encoding) and caught
by address sanitizer.
Ian Rogers (6):
perf cpumap: Const map for max
perf cpumap: Synthetic events and const/static
perf cpumap: Compute mask size in constant time
perf cpumap: Fix alignment for masks in event encoding
perf events: Prefer union over variable length array
perf cpumap: Add range data encoding
tools/lib/perf/cpumap.c | 2 +-
tools/lib/perf/include/perf/cpumap.h | 2 +-
tools/lib/perf/include/perf/event.h | 61 ++++++++-
tools/perf/tests/cpumap.c | 71 ++++++++---
tools/perf/tests/event_update.c | 14 +--
tools/perf/util/cpumap.c | 111 +++++++++++++---
tools/perf/util/cpumap.h | 4 +-
tools/perf/util/event.h | 4 -
tools/perf/util/header.c | 24 ++--
tools/perf/util/session.c | 35 +++---
tools/perf/util/synthetic-events.c | 182 +++++++++++++--------------
tools/perf/util/synthetic-events.h | 2 +-
12 files changed, 327 insertions(+), 185 deletions(-)
--
2.36.1.476.g0c4daa206d-goog
next reply other threads:[~2022-06-14 14:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 14:33 Ian Rogers [this message]
2022-06-14 14:33 ` [PATCH v2 1/6] perf cpumap: Const map for max Ian Rogers
2022-06-14 14:33 ` [PATCH v2 2/6] perf cpumap: Synthetic events and const/static Ian Rogers
2022-06-14 14:33 ` [PATCH v2 3/6] perf cpumap: Compute mask size in constant time Ian Rogers
2022-06-14 14:33 ` [PATCH v2 4/6] perf cpumap: Fix alignment for masks in event encoding Ian Rogers
2022-06-14 22:44 ` Namhyung Kim
2022-06-14 23:51 ` Ian Rogers
2022-06-29 9:18 ` Jiri Olsa
2022-06-29 16:05 ` Ian Rogers
2022-08-18 21:50 ` Arnaldo Carvalho de Melo
2022-08-18 22:49 ` Ian Rogers
2022-08-19 15:58 ` Arnaldo Carvalho de Melo
2022-08-19 17:09 ` Ian Rogers
2022-08-19 17:28 ` Arnaldo Carvalho de Melo
2022-08-26 12:57 ` Alexander Gordeev
2022-08-26 16:20 ` Ian Rogers
2022-06-14 14:33 ` [PATCH v2 5/6] perf events: Prefer union over variable length array Ian Rogers
2022-06-14 14:33 ` [PATCH v2 6/6] perf cpumap: Add range data encoding Ian Rogers
2022-06-29 9:31 ` Jiri Olsa
2022-06-29 16:19 ` Ian Rogers
2022-07-31 12:39 ` Jiri Olsa
2022-08-04 19:30 ` Ian Rogers
2022-09-07 22:41 ` Ian Rogers
2022-09-07 23:47 ` Arnaldo Carvalho de Melo
2022-09-08 18:52 ` Arnaldo Carvalho de Melo
2022-07-15 17:01 ` [PATCH v2 0/6] Corrections to cpu map event encoding Ian Rogers
2022-07-29 2:01 ` Ian Rogers
2022-07-29 11:35 ` Jiri Olsa
2022-07-29 14:28 ` Ian Rogers
2022-07-31 12:37 ` Jiri Olsa
2022-08-04 20:23 ` Jiri Olsa
[not found] ` <CAP-5=fX-Ex1uv0hxCwDkkAyFV6VQNPRB5uSPpCDNgqu5ZV=bCA@mail.gmail.com>
2022-08-16 19:51 ` Arnaldo Carvalho de Melo
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=20220614143353.1559597-1-irogers@google.com \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.v.bayduraev@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=colin.king@intel.com \
--cc=davemarchevsky@fb.com \
--cc=eranian@google.com \
--cc=german.gomez@arm.com \
--cc=gustavoars@kernel.org \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=keescook@chromium.org \
--cc=leo.yan@linaro.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 \
--cc=rickyman7@gmail.com \
--cc=songliubraving@fb.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 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).