public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@hpl.hp.com>
To: Tony Luck <tony.luck@gmail.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, perfmon@napali.hpl.hp.com,
	linux-ia64@vger.kernel.org, perfctr-devel@lists.sourceforge.net
Subject: Re: [Perfctr-devel] Re: quick overview of the perfmon2 interface
Date: Tue, 20 Dec 2005 10:16:08 -0800	[thread overview]
Message-ID: <20051220181608.GD5516@frankl.hpl.hp.com> (raw)
In-Reply-To: <12c511ca0512201005k4d499b57v724815258f80322@mail.gmail.com>

Andrew,

I will reply to your comments in details.

On Tue, Dec 20, 2005 at 10:05:11AM -0800, Tony Luck wrote:
> > >       The interface also supports automatic randomization of the reset value
> > >       for a PMD after an overflow.
> >
> > Why would one want to randomise the PMD after an overflow?
> 
> To get better data.  Using a constant reload value may keep measuring the
> same spot in the application if you are using a sample frequency that
> matches some repeat pattern in the application (and Murphy's law says
> that you'll hit this a lot).
> 
Yes, Tony is right.

For several sampling measurments which are using events that occur very
frequently such as branches, it becomes very important to avoid getting
in lockstep with the execution. Using prime numbers is not always enough
and randomization is the best way to solve this problem.

We have ecountered this when David Mosberger was developing
q-syscollect for Linux/IA64. This tool is sampling return branches
using the MckInley Branch Trace Buffer. With the collected samples
it is possible to build a statistical call graph (a la gprof).
Without randomization, the samples were so biased that the data
was unusable. With randomization, the data was very close to actual
call graph as measured by gprof. The same argument applies to
sampling for cache misses, you want to make sure you are not
always capturing the same cache misses. 

The random number generator does not have to be super fancy. That's why
we use the Carta algorithm, it is simple and fast and gives us very
good samples.

-- 

-Stephane

  reply	other threads:[~2005-12-20 18:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-19 11:31 quick overview of the perfmon2 interface Stephane Eranian
2005-12-20 10:51 ` Andrew Morton
2005-12-20 11:19   ` [Perfctr-devel] " Mikael Pettersson
2005-12-20 18:05   ` Tony Luck
2005-12-20 18:16     ` Stephane Eranian [this message]
2005-12-20 23:52   ` [Perfctr-devel] " David Gibson
2005-12-22 11:56   ` Stephane Eranian
2005-12-22 12:05     ` Christoph Hellwig
2005-12-22 15:37       ` [Perfctr-devel] " William Cohen
2005-12-22 17:23         ` Christoph Hellwig
2005-12-22 18:17           ` William Cohen
2005-12-22 18:36           ` John Reiser
2005-12-22 18:48   ` [perfmon] " Stephane Eranian

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=20051220181608.GD5516@frankl.hpl.hp.com \
    --to=eranian@hpl.hp.com \
    --cc=akpm@osdl.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perfctr-devel@lists.sourceforge.net \
    --cc=perfmon@napali.hpl.hp.com \
    --cc=tony.luck@gmail.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