linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: David Ahern <daahern@cisco.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	mingo@elte.hu, acme@ghostprotocols.net, paulus@samba.org
Subject: Re: [PATCH 1/3] perf events: fix WARN_ON_ONCE for 64-bit raw data, SW events
Date: Fri, 18 Feb 2011 15:55:38 +0100	[thread overview]
Message-ID: <1298040938.5226.771.camel@laptop> (raw)
In-Reply-To: <4D5E8338.8010602@cisco.com>

On Fri, 2011-02-18 at 07:33 -0700, David Ahern wrote:
> 
> On 02/18/11 04:00, Peter Zijlstra wrote:
> > On Thu, 2011-02-17 at 22:53 -0700, David Ahern wrote:
> >> This check does not work out for 64-bit counter:
> >>
> >>     sizeof(u32) + sizeof(u64) = 4 + 8 = 12
> >>
> >> which does not pass the WARN_ON_ONCE test. I'm guessing (hoping
> >> really) that the intent is that the size of the raw data is a
> >> multiple of 4 bytes, not 8.
> > 
> > No the data must come in 8bytes strides.
> > 
> 
> Then the sizeof the size field needs to be moved to u64; right now it is
> u32:

That's a false conclusion.

> struct perf_raw_record {
>     u32             size;
>     void                *data;
> };

> So size should be changed to u64 rather than modifying the WARN_ON_ONCE?

No.

> Another gotcha is in perf_output_sample there is:
>             struct {
>                 u32 size;
>                 u32 data;
>             } raw = {
>                 .size = sizeof(u32),
>                 .data = 0,
>             };
> 
> While that meets the 8-byte stride I was concerned that changing the
> size field to u64 breaks ABI.

It would.

No, what you need to do is provide data that is sized such that it
matches the 8b stride adding padding where needed.

Anyway, I don't think you need RAW at all.

  parent reply	other threads:[~2011-02-18 14:54 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-18  5:53 [PATCH 0/3] perf events: Add realtime clock event and timehist option David Ahern
2011-02-18  5:53 ` [PATCH 1/3] perf events: fix WARN_ON_ONCE for 64-bit raw data, SW events David Ahern
2011-02-18 11:00   ` Peter Zijlstra
2011-02-18 14:33     ` David Ahern
2011-02-18 14:53       ` Arnaldo Carvalho de Melo
2011-02-18 15:01         ` Peter Zijlstra
2011-02-18 17:04           ` Arnaldo Carvalho de Melo
2011-02-18 17:13             ` Peter Zijlstra
2011-02-18 17:15               ` David Ahern
2011-02-18 17:17                 ` David Ahern
2011-02-18 14:55       ` Peter Zijlstra [this message]
2011-02-18 15:28         ` David Ahern
2011-02-18 15:51           ` Peter Zijlstra
2011-02-18  5:53 ` [PATCH 2/3] perf events: Introduce realtime clock event David Ahern
2011-02-18 11:14   ` Peter Zijlstra
2011-02-18 14:39     ` David Ahern
2011-02-18 14:58       ` Peter Zijlstra
2011-02-18 15:35         ` David Ahern
2011-02-18 15:39         ` David Ahern
2011-02-20 12:49         ` Ingo Molnar
2011-02-18  5:53 ` [PATCH 3/3] perf events: add timehist option to record and report David Ahern
2011-02-18  7:06   ` Ingo Molnar
2011-02-18 14:28     ` David Ahern
2011-02-18 17:59       ` Frederic Weisbecker
2011-02-18 18:07         ` David Ahern
2011-02-18 18:39           ` Peter Zijlstra
2011-02-18 18:45             ` David Ahern
2011-02-19  9:32               ` Ingo Molnar
2011-02-19 14:38                 ` Arnaldo Carvalho de Melo
2011-02-18 19:24           ` Frederic Weisbecker
2011-02-18 19:53             ` David Ahern
2011-02-21 21:13               ` Frederic Weisbecker
2011-02-18 18:41         ` Arnaldo Carvalho de Melo
2011-02-18 18:47           ` David Ahern
2011-02-18 18:53           ` David Ahern
2011-02-18 19:06             ` Arnaldo Carvalho de Melo
2011-02-18 19:29           ` Frederic Weisbecker
2011-02-18 20:30             ` Arnaldo Carvalho de Melo
2011-02-21 21:17               ` Frederic Weisbecker

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=1298040938.5226.771.camel@laptop \
    --to=peterz@infradead.org \
    --cc=acme@ghostprotocols.net \
    --cc=daahern@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@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).