mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: David Ahern <dsahern@gmail.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 6/7] perf, tool: Fix endianity trick for adds_features bitmask
Date: Thu, 24 May 2012 21:48:34 +0200	[thread overview]
Message-ID: <20120524194834.GC2346@m.redhat.com> (raw)
In-Reply-To: <4FBE547A.5020900@gmail.com>

On Thu, May 24, 2012 at 09:32:10AM -0600, David Ahern wrote:
> On 5/23/12 11:59 AM, Jiri Olsa wrote:
> >On Tue, May 22, 2012 at 09:48:09AM -0600, David Ahern wrote:
> >>On 5/22/12 2:41 AM, Jiri Olsa wrote:
> >>
> >>>hm, any special details for the record? because I'm sure I tested this way..
> >>>
> >>>I'll retest, thanks
> >>>jirka
> >>
> >>
> >>The attached fixes it.
> >
> >>commit 1353676ca6551a0165df030784ada20ebea73f73
> >>Author: David Ahern<dsahern@gmail.com>
> >>Date:   Tue May 22 09:40:17 2012 -0600
> >>
> >>     perf, tool: Fix endianity swapping for adds_features bitmask
> >>
> >>     Based on Jiri's latest attempt:
> >>     https://lkml.org/lkml/2012/5/16/61
> >>
> >>     Basically, adds_features should be byte swapped assuming unsigned
> >>     longs are either 8-bytes (u64) or 4-bytes (u32).
> >>
> >>     Fixes 32-bit ppc dumping 64-bit x86 feature data:
> >>      ========
> >>      captured on: Sun May 20 19:23:23 2012
> >>      hostname : nxos-vdc-dev3
> >>      os release : 3.4.0-rc7+
> >>      perf version : 3.4.rc4.137.g978da3
> >>      arch : x86_64
> >>      nrcpus online : 16
> >>      nrcpus avail : 16
> >>      cpudesc : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz
> >>      cpuid : GenuineIntel,6,26,5
> >>      total memory : 24680324 kB
> >>     ...
> >>
> >>     Verified 64-bit x86 can still dump feature data for 32-bit ppc.
> >>
> >>     Signed-off-by: David Ahern<dsahern@gmail.com>
> >
> >I got the header properly displayed with this patch, but I'm getting
> >following diffs in the perf report output (ppc32 vs x86_64):
> >(after moving origin perf archive build-id cache to target system)
> >
> >-     0.00%            perf  [ext4]               [k] 0x0005b318
> >+     0.00%            perf  [ext4]               [k] .cleanup_module
> >
> >-     0.00%             yes  [kernel.kallsyms]    [k] .sys_write
> >+     0.00%             yes  [kernel.kallsyms]    [k] .SyS_write
> >
> >  ^^^ this one is particularly disturbing ;)
> >
> >I guess it's unrelated to the header stuff which your patch fixes
> >properly I think, but I got small conflict rebasing this to current tip
> >
> >Reviewed-by: Jiri Olsa<jolsa@redhat.com>
> 
> That is odd... and if you are getting that much you are ahead of me.
> When I analyze an x86_64 file on ppc32 all symbols show as
> kernel.kallsyms dso.

I made some load and collected wide system data

> 
> The patch applies cleanly for me on latest acme/core:
> $ patch -p1 < perf-swap-features.patch
> patching file tools/perf/util/header.c
> patching file tools/perf/util/include/linux/bitops.h
> patching file tools/perf/util/session.c
> patching file tools/perf/util/session.h

hm, I had some troubles aplying this to current tip, maybe it's ok now

I'll deal with this issue and send the rest of the patches (updated with
your comments) I have together with the new fix.

jirka

  reply	other threads:[~2012-05-24 19:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-16  6:59 [PATCHv4 0/7] perf, tool: Fix endian issues Jiri Olsa
2012-05-16  6:59 ` [PATCH 1/7] perf, tool: Handle different endians properly during symbol load Jiri Olsa
2012-05-22  3:26   ` David Ahern
2012-05-16  6:59 ` [PATCH 2/7] perf, tool: Carry perf_event_attr bitfield throught different endians Jiri Olsa
2012-05-22  3:29   ` David Ahern
2012-05-23 15:26   ` [tip:perf/core] perf tools: " tip-bot for Jiri Olsa
2012-05-16  6:59 ` [PATCH 3/7] perf, tool: Add union u64_swap type for swapping u64 data Jiri Olsa
2012-05-22  3:29   ` David Ahern
2012-05-23 15:27   ` [tip:perf/core] perf tools: " tip-bot for Jiri Olsa
2012-05-16  6:59 ` [PATCH 4/7] perf, tool: Handle endianity swap on sample_id_all header data Jiri Olsa
2012-05-22  3:35   ` David Ahern
2012-05-16  6:59 ` [PATCH 5/7] perf, tool: Fix 32 bit values endianity swap for sample_id_all header Jiri Olsa
2012-05-22  4:38   ` David Ahern
2012-05-22 15:53     ` Arnaldo Carvalho de Melo
2012-05-16  6:59 ` [PATCH 6/7] perf, tool: Fix endianity trick for adds_features bitmask Jiri Olsa
2012-05-22  4:38   ` David Ahern
2012-05-22  8:41     ` Jiri Olsa
2012-05-22 15:48       ` David Ahern
2012-05-23 17:59         ` Jiri Olsa
2012-05-24 15:32           ` David Ahern
2012-05-24 19:48             ` Jiri Olsa [this message]
2012-06-15 19:10         ` [tip:perf/urgent] perf tools: Fix endianity swapping " tip-bot for David Ahern
2012-05-16  6:59 ` [PATCH 7/7] perf, tool: Fix callchain ip printf Jiri Olsa
2012-05-21  7:39   ` [tip:perf/core] perf hists: Fix callchain ip printf format tip-bot for 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=20120524194834.GC2346@m.redhat.com \
    --to=jolsa@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=cjashfor@linux.vnet.ibm.com \
    --cc=dsahern@gmail.com \
    --cc=fweisbec@gmail.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

Powered by JetHome