From: David Ahern <dsahern@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@redhat.com, a.p.zijlstra@chello.nl, mingo@elte.hu,
paulus@samba.org, cjashfor@linux.vnet.ibm.com,
fweisbec@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] perf, tool: Fix endianity trick for adds_features bitmask
Date: Mon, 07 May 2012 10:15:09 -0600 [thread overview]
Message-ID: <4FA7F50D.1060906@gmail.com> (raw)
In-Reply-To: <1336390149-2970-6-git-send-email-jolsa@redhat.com>
On 5/7/12 5:29 AM, Jiri Olsa wrote:
> Addons bitmask is stored as array of unsigned long values. The size
> of the unsigned long is same as pointer size for architecture, so it
> could differ for each architecture.
>
> To handle the endianity for adds_features bitmask, we first swap the
> bitmaks as u64 values and check for HEADER_HOSTNAME bit. If not set we
> want to unswap the u64 values and swap the adds_features as u32 values.
>
> This is currently buggy, since we swap just first 32bits of each u64
> value. Adding swap of the next 32 bits as well. Also adding& using
> BITS_TO_U64 instead of BITS_TO_LONGS as counter max due to the different
> size of unsigned longs per architecture.
>
> Note, running following to test perf endianity handling:
> - origin system:
> # perf record -a -- sleep 10 (any perf record will do)
> # perf report> report.origin
> # perf archive perf.data
>
> - copy the perf.data, report.origin and perf.data.tar.bz2
> to a target system and run:
> # tar xjvf perf.data.tar.bz2 -C ~/.debug
> # perf report> report.target
> # diff -u report.origin report.target
>
> - the diff should produce no output
> (besides some white space stuff and possibly different
> date/TZ output)
Did you cross bitness and architectures in your test? When I added the
code you are modifying I verified it worked by analyzing 32-bit PPC
files on 64-bit x86 and 32-bit x86.
Did you also test old versus new perf commands? perf data collected with
older command and analyzed with a newer version with this patch? Be sure
to add the -I switch to get all the processing of the feature mask.
David
>
> Signed-off-by: Jiri Olsa<jolsa@redhat.com>
> ---
> tools/perf/util/header.c | 20 +++++++++++++++-----
> tools/perf/util/include/linux/bitops.h | 1 +
> 2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index c0b70c6..a56db7e 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -1963,13 +1963,23 @@ int perf_file_header__read(struct perf_file_header *header,
> * file), punt and fallback to the original behavior --
> * clearing all feature bits and setting buildid.
> */
> - for (i = 0; i< BITS_TO_LONGS(HEADER_FEAT_BITS); ++i)
> - header->adds_features[i] = bswap_64(header->adds_features[i]);
> +
> + mem_bswap_64(&header->adds_features,
> + BITS_TO_U64(HEADER_FEAT_BITS));
>
> if (!test_bit(HEADER_HOSTNAME, header->adds_features)) {
> - for (i = 0; i< BITS_TO_LONGS(HEADER_FEAT_BITS); ++i) {
> - header->adds_features[i] = bswap_64(header->adds_features[i]);
> - header->adds_features[i] = bswap_32(header->adds_features[i]);
> + u64 *v = (u64 *)&header->adds_features;
> +
> + for (i = 0; i< BITS_TO_U64(HEADER_FEAT_BITS); ++i) {
> + union {
> + u64 val64;
> + u32 val32[2];
> + } u;
> +
> + u.val64 = *v++;
> + u.val64 = bswap_64(u.val64);
> + u.val32[0] = bswap_32(u.val32[0]);
> + u.val32[1] = bswap_32(u.val32[1]);
> }
> }
>
> diff --git a/tools/perf/util/include/linux/bitops.h b/tools/perf/util/include/linux/bitops.h
> index f1584833..10096cb 100644
> --- a/tools/perf/util/include/linux/bitops.h
> +++ b/tools/perf/util/include/linux/bitops.h
> @@ -8,6 +8,7 @@
> #define BITS_PER_LONG __WORDSIZE
> #define BITS_PER_BYTE 8
> #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
> +#define BITS_TO_U64(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(u64))
>
> #define for_each_set_bit(bit, addr, size) \
> for ((bit) = find_first_bit((addr), (size)); \
next prev parent reply other threads:[~2012-05-07 16:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-07 11:29 [PATCHv3 0/5] perf, tool: Fix endian issues Jiri Olsa
2012-05-07 11:29 ` [PATCH 1/5] perf, tool: Handle different endians properly during symbol load Jiri Olsa
2012-05-07 11:29 ` [PATCH 2/5] perf, tool: Carry perf_event_attr bitfield throught different endians Jiri Olsa
2012-05-07 11:29 ` [PATCH 3/5] perf, tool: Handle endianity swap on sample_id_all header data Jiri Olsa
2012-05-07 11:29 ` [PATCH 4/5] perf, tool: Fix 32 bit values endianity swap for sample_id_all header Jiri Olsa
2012-05-07 11:29 ` [PATCH 5/5] perf, tool: Fix endianity trick for adds_features bitmask Jiri Olsa
2012-05-07 16:15 ` David Ahern [this message]
2012-05-08 2:12 ` [PATCHv3 0/5] perf, tool: Fix endian issues David Ahern
2012-05-08 3:37 ` David Ahern
2012-05-08 3:49 ` David Ahern
2012-05-10 10:38 ` Jiri Olsa
2012-05-10 16:30 ` Jiri Olsa
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=4FA7F50D.1060906@gmail.com \
--to=dsahern@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=fweisbec@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.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).