All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Milian Wolff <mail@milianw.de>,
	linux-perf-users <linux-perf-users@vger.kernel.org>
Subject: Re: Size of perf data files
Date: Thu, 27 Nov 2014 10:19:16 -0300	[thread overview]
Message-ID: <20141127131916.GH30226@kernel.org> (raw)
In-Reply-To: <87oarto40a.fsf@sejong.aot.lge.com>

Em Thu, Nov 27, 2014 at 09:56:21AM +0900, Namhyung Kim escreveu:
> Hi Milian,
> 
> On Wed, 26 Nov 2014 19:11:01 +0100, Milian Wolff wrote:
> > I tried this on a benchmark of mine:
> >
> > before:
> > [ perf record: Woken up 196 times to write data ]
> > [ perf record: Captured and wrote 48.860 MB perf.data (~2134707 samples) ]
> >
> > after, with dwarf,512
> > [ perf record: Woken up 18 times to write data ]
> > [ perf record: Captured and wrote 4.401 MB perf.data (~192268 samples) ]
> >
> > What confuses me though is the number of samples. When the workload is equal, 
> > shouldn't the number of samples stay the same? Or what does this mean? The 
> > resulting reports both look similar enough.
> 
> It's bogus - it just calculates the number of samples based on the file
> size (with fixed sample size).  I think we should either show the correct
> number as we post-process samples for build-id detection or simply
> remove it.

Well, since we setup the perf_event_attr we could perhaps do a better
job at estimating this... In this case we even know how much stack_dump
we will take at each sample, that would be major culprit for the current
mis estimation.

And yes, if we do the post processing, we can do a precise calculation.

- Arnaldo

  reply	other threads:[~2014-11-27 13:19 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26 12:47 Size of perf data files Milian Wolff
2014-11-26 16:06 ` Arnaldo Carvalho de Melo
2014-11-26 18:11   ` Milian Wolff
2014-11-27  0:56     ` Namhyung Kim
2014-11-27 13:19       ` Arnaldo Carvalho de Melo [this message]
2014-11-28  6:18         ` Namhyung Kim
2014-11-26 20:48 ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2015-01-06  3:21 Yale Zhang
2015-01-06  5:39 ` Andi Kleen
2015-01-06 21:02   ` Yale Zhang
2015-01-06 21:29     ` Andi Kleen
2015-01-09  2:06     ` Frank Ch. Eigler

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=20141127131916.GH30226@kernel.org \
    --to=acme@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mail@milianw.de \
    --cc=namhyung@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.