All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vince Weaver <vince@deater.net>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Stephane Eranian <eranian@googlemail.com>,
	Eric Dumazet <dada1@cosmosbay.com>,
	Robert Richter <robert.richter@amd.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Peter Anvin <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>,
	"David S. Miller" <davem@davemloft.net>,
	perfctr-devel@lists.sourceforge.net
Subject: Re: [patch] Performance Counters for Linux, v4
Date: Tue, 16 Dec 2008 12:38:59 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0812161232170.6249@pianoman.cluster.toy> (raw)
In-Reply-To: <20081214212829.GA9435@elte.hu>


I'm trying to evaluate this new proposal for the kind of workloads I use 
performance counters for, and even the simplest tests don't work.

I'm trying to do a simple aggragate count for some benchmarks here using 
timec and I'm getting poor results.

Are any of the problems I'm reporting going to be fixed?

In any case, I was testing aggregate counts on a longer running benchmark, 
this time equake from the spec2k benchmark suite, still on the q6600.

If I only count retired instructions, I get consistent results:

   timec -e 1

       119175255369  instructions         (events)
       119175255561  instructions         (events)
       119175255383  instructions         (events)


however the minute I add another count, say cycles so I can calculate 
CPI/IPC the results for instructions are suddenly off by 33%.

Needless to say, perfmon can handle reading both cycles and instructions 
at the same time.


   timec -e 0, -e 1
        91758816320  cycles               (events)
        79428247907  instructions         (events)

        91849140396  cycles               (events)
        79449560742  instructions         (events)


It gets worse when trying to look at cache statistics:

    timec -e 1 -e 2 -e 3

        59611457943  instructions         (events)
         1872499771  cache references     (events)
           97471971  cache misses         (events)

        59601907232  instructions         (events)
         1871766376  cache references     (events)
           97435199  cache misses         (events)

and so on

    timec -e1 -e2 -e3 -e4


        47671703285  instructions         (events)
         1498246999  cache references     (events)
           77838085  cache misses         (events)
         3394839360  branches             (events)

        47666131604  instructions         (events)
         1497069685  cache references     (events)
           78065325  cache misses         (events)
         3393244879  branches             (events)



So apparently this performance counter infrastructure will always be 
useless for trying to get plain aggregate counts?  It's the simplest case 
to get right, so it makes me wonder about the design of the rest of the 
infrastructure.

Vince

  parent reply	other threads:[~2008-12-16 17:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-14 21:28 [patch] Performance Counters for Linux, v4 Ingo Molnar
2008-12-15 11:59 ` Paul Mackerras
2008-12-15 12:11 ` Paul Mackerras
2008-12-16 14:22   ` Peter Zijlstra
2008-12-16 23:06     ` Paul Mackerras
2008-12-16 23:51       ` Ingo Molnar
2008-12-17  1:55       ` Andi Kleen
2009-01-16 18:01         ` Corey Ashford
2009-01-16 22:14           ` Maynard Johnson
2009-01-16 23:11             ` Ingo Molnar
2009-01-17  1:26           ` Paul Mackerras
2009-01-17  9:53             ` Andi Kleen
2008-12-17  2:23       ` [Perfctr-devel] " Dan Terpstra
2008-12-17  7:34       ` stephane eranian
2008-12-15 17:44 ` Vince Weaver
2008-12-15 21:07   ` Vince Weaver
2008-12-15 22:13     ` Paul Mackerras
2008-12-15 21:42   ` Paul Mackerras
2008-12-15 22:03     ` stephane eranian
2008-12-16 14:42     ` Peter Zijlstra
2008-12-16 16:55       ` Vince Weaver
2008-12-16 21:52         ` Paul Mackerras
2008-12-16 12:22 ` Pavel Machek
2008-12-16 12:50   ` Ingo Molnar
2008-12-16 12:57     ` Pavel Machek
2008-12-16 13:03       ` Ingo Molnar
2008-12-16 13:13         ` Arjan van de Ven
2008-12-16 20:04           ` Pavel Machek
2008-12-16 14:45 ` Peter Zijlstra
2008-12-16 15:46 ` [Perfctr-devel] " Martin Cracauer
2008-12-16 17:38 ` Vince Weaver [this message]
2008-12-16 19:47   ` Corey Ashford
2008-12-16 20:55     ` Vince Weaver
2008-12-16 19:56 ` [Perfctr-devel] " William Cohen
2008-12-17  1:51   ` Andi Kleen
2008-12-17  1:56     ` Samuel Thibault
     [not found]       ` <d484eb1f0812162357n7a851f2fncc0abaae9bd293a4@mail.gmail.com>
2008-12-17  9:18         ` Andi Kleen
     [not found]           ` <d484eb1f0812170611s597e014cl5fb98d6dd81afd49@mail.gmail.com>
2008-12-17 15:06             ` Andi Kleen
2008-12-17 16:00 ` William Cohen
2008-12-17 20:53   ` Corey Ashford

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=Pine.LNX.4.64.0812161232170.6249@pianoman.cluster.toy \
    --to=vince@deater.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --cc=eranian@googlemail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=perfctr-devel@lists.sourceforge.net \
    --cc=robert.richter@amd.com \
    --cc=tglx@linutronix.de \
    /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.