What happens if you count PAGE_WALK_TYPE:DTMISS:ITMISS?
I suspect Stephane's right that the second counter assignment is probably
messed up. Pentium4's a beast...
- d
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:perfmon2-devel-
> [EMAIL PROTECTED] On Behalf Of stephane eranian
>
Stephane -
We applied your patch to a fresh checkout of libpfm and tried it on our
newly patched Montecito. It failed with a "function not implemented" error
on a call to pfm_create_context. I'm guessing there needs to be a separate
case in the switch for Montecito. I only saw a generic __ia64__
We
---Original Message-----
> From: Dan Terpstra [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 03, 2008 4:40 PM
> To: 'stephane eranian'; 'perfmon2-devel@lists.sourceforge.net'
> Subject: RE: [perfmon2] libpfm syscall patch
>
> Stephane -
> We applied your pat
I'm working on implementing PAPI on Cell.
And I'm confused.
Can someone tell me why pfm_get_num_counters() returns 8 for Cell (I think
this is # of 16-bit counters?) when pfm_cell_get_event_code() compares
against a hard-coded limit of 2 (see below)? Could this limit simply have
been inappropriatel
sure would like some
confirmation of that.
- dan
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 4:54 PM
> To: Carl Love
> Cc: Dan Terpstra; perfmon2-devel@lists.sourceforge.net
> Subject: Re: [perfmon2] perfmon2 on Cell
&
hardcode this as 2,
and where is the limit of 4 32 bit counters defined/enforced?
- d
> -Original Message-
> From: Dan Terpstra [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 08, 2008 4:16 PM
> To: '[EMAIL PROTECTED]'; 'Carl Love'
> Cc: 'perfmon2-de
port.num_cnt) {
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 09, 2008 4:03 PM
> To: Carl Love
> Cc: Dan Terpstra; perfmon2-devel@lists.sourceforge.net
> Subject: Re: [perfmon2] perfmon2 on Cell
>
> Carl,
>
> Concerni
Works great.
Thanks.
- d
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 09, 2008 7:01 PM
> To: Dan Terpstra
> Cc: Carl Love; perfmon2-devel@lists.sourceforge.net
> Subject: Re: [perfmon2] perfmon2 on Cell
>
> Da
Hi -
In preliminary testing of PAPI on perfmon2/Cell, it appears that the CYCLES
event produced by pfm_get_cycle_event() is not virtualized beyond 32 bits.
One of the basic PAPI tests shows this quite clearly:
[EMAIL PROTECTED] src]$ ctests/first
Test case 1: Non-overlapping start, stop, read.
---
l Love [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 12, 2008 4:41 PM
> To: [EMAIL PROTECTED]
> Cc: Dan Terpstra; perfmon2-devel@lists.sourceforge.net
> Subject: Re: [perfmon2] CYCLES overflow on perfmon2 on Cell
>
> Yes, I was actually referring to the HW configuration being d
to be
ironed out.
- d
> -Original Message-
> From: Carl Love [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 12, 2008 5:39 PM
> To: Dan Terpstra
> Cc: [EMAIL PROTECTED]; perfmon2-devel@lists.sourceforge.net
> Subject: RE: [perfmon2] CYCLES overflow on perfmon2 on Cell
>
d
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 12, 2008 6:48 PM
> To: Carl Love
> Cc: Dan Terpstra; perfmon2-devel@lists.sourceforge.net
> Subject: Re: [perfmon2] CYCLES overflow on perfmon2 on Cell
>
> Carl,
>
Yoshio -
I agree that we need to resolve the 16/32 bit counter issue.
Does Toshiba support a completely different kernel patch from IBM?
If Toshiba uses both 16 and 32 bit counters, shouldn't PMU_CELL_NUM_COUNTERS
in pfmlib_cell.h somehow reflect that rather than being hard-coded to 8?
How does one
This is a case of "don't shoot the messenger".
PAPI/perfmon is merely reporting the FLOP rate of the program in question.
Simple loops often don't come anywhere close to optimized routines like BLAS
or linpack. Remember that PAPI will only measure a single core, so quoting
the theoretical GFLOPS f
BTW, this (or something that changed between today and last Friday) also
fixed a problem I had with identifying an Intel Core2Duo, fam 6 model 15,
stepping 11.
- d
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:perfmon2-devel-
> [EMAIL PROTECTED] On Behalf Of stephane eranian
> Sen
Depends on what you mean by 'heavily'. PAPI calls it in two places: once in
the PAPI_stop functionality, to basically clean things up; and once in a
routine that checks multiplexing behavior and creates a scratch event set
for testing. Seems that for long-running applications where calipers may
com
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 08, 2008 4:34 PM
> To: Dan Terpstra
> Cc: perfmon2-devel
> Subject: Re: [perfmon2] pfm_delete_evtsets() going away in v3
>
> Dan,
>
> On Wed, Sep 3, 2008 at
W. Krentel [mailto:[EMAIL PROTECTED]
> Sent: Sunday, September 21, 2008 4:55 PM
> To: Dan Terpstra
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Ptools-perfapi] PAPI 3.6.2
>
> I see the following regression related to configuring PAPI on systems
> with perfmon 2.8 and 2.81 between PAP
As Harpertown is an Intel Core2 chip, it should be supported by the current
versions of PAPI and perfmon2.
Does anyone know anything different?
- d
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ptools-perfapi-
> [EMAIL PROTECTED] On Behalf Of Daniel Thomas
> Sent: Wednesday, Octob
Yep. 6/23 is a Core2. Should be supported.
- d
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:ptools-perfapi-
> [EMAIL PROTECTED] On Behalf Of Daniel Thomas
> Sent: Wednesday, October 29, 2008 11:38 AM
> To: [EMAIL PROTECTED]
> Cc: perfmon2-devel@lists.sourceforge.net; [EMAIL PROTE
And PAPI support should follow closely behind.
- d
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 29, 2008 2:08 PM
> To: Daniel Thomas
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; perfmon2-
> [EMAIL PROTECTED]
> Subject: Re: [perfmon2] [Pt
Hmmm...
An awful lot of events with an x.y.z naming structure. This could cause a
combinatorial explosion. Also, what the heck's an UnCore?
- d
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 27, 2008 6:12 AM
> To: perfmon2-devel
> Subjec
So I spent the day cuddled up with my pdf of Intel Vol 3B, re-reading
Chapter 18 with a hope of understanding i7.
If any of the below is muddled or just plain wrong, I'd welcome
clarification...
Looks to me like there's 3 fixed counters, just like the good ol' days, and
4 programmable counters w
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 01, 2008 11:09 PM
> To: Dan Terpstra
> Cc: perfmon2-devel
> Subject: Re: [perfmon2] Intel Core i7 specs available.
>
> Dan,
>
> On Mon, Dec 1, 2008 at
h domains at once...
- d
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2008 12:54 PM
> To: Dan Terpstra
> Cc: perfmon2-devel
> Subject: Re: [perfmon2] Intel Core i7 specs available.
>
> Dan,
>
> On Tu
> -Original Message-
> From: stephane eranian [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2008 8:45 PM
> To: Dan Terpstra
> Cc: perfmon2-devel
> Subject: Re: [perfmon2] Intel Core i7 specs available.
>
> On Wed, Dec 3, 2008 at 2:43 AM, Dan Te
PAPI's first-person event-set caliper model essentially useless. We must be
able to start and stop multiple counter values simultaneously and quickly to
infer any validity even for derived measurements as simple as
instructions-per-cycle.
dan terpstra
for the PAPI team
> -Original Mess
n's been part of the
Itanium linux kernel since day one...
Dan Terpstra
for
the PAPI team
> -Original Message-
> From: Jack Perdue [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 09, 2008 1:38 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [Perfctr-de
Great news. Thanks!
I'll give the libpfm part a spin in PAPI on perfctr this week.
- d
> -Original Message-
> From: stephane eranian [mailto:eran...@googlemail.com]
> Sent: Monday, January 12, 2009 12:13 PM
> To: perfmon2-devel
> Subject: [perfmon2] Intel Nehalem support
>
> Hello,
>
> I
We're trying to patch a dual core Opteron with perfmon and coming up with an
undefined label: __NR_ia32_pfm_create_context.
Has anyone else seen this? What are we missing?
- dan terpstra
Here's the details:
INFO:
Kernel 2.6.27 initial release
Perfmon2 dated 10-13-08
OS:
Phil -
Thanks for tracking this down. Looks like the problem *is* in libpfm. The
event name is LAST_LEVEL_CACHE_REFERENCES everywhere except in
libpfm/lib/coreduo_events.h. Intel is no help, listing the mnemonic as "LLC
Reference" and the description as "LL cache references".
Stephane -
I think thi
> > I don't think PAPI's solution really solves the "quick load time + small
> > foot print" issue for libpfm. If you just used caching, I think it
> solves
> > both problems, but would require that the XML file be available
> somewhere
> > when libpfm is loaded up the first time. If the XML fi
Stephane -
This looks good. Am I correct in assuming that it's backward compatible with
earlier libpfm syntax? In other words, if I *don't* specify the new
attributes, will they default to the values used in earlier versions?
- d
> -Original Message-
> From: stephane eranian [mailto:eran..
safe assumption?
- d
> -Original Message-
> From: stephane eranian [mailto:eran...@googlemail.com]
> Sent: Friday, June 19, 2009 11:03 AM
> To: Dan Terpstra
> Cc: perfmon2-devel
> Subject: Re: [perfmon2] libpfm4 progress
>
> On Fri, Jun 19, 2009 at 5:01 PM, Dan Terpstra
> -Original Message-
> From: stephane eranian [mailto:eran...@googlemail.com]
> Sent: Friday, June 19, 2009 11:14 AM
> To: Dan Terpstra
> Cc: perfmon2-devel
> Subject: Re: [perfmon2] libpfm4 progress
>
> On Fri, Jun 19, 2009 at 5:09 PM, Dan Terpstra
> wrote
Martin -
Phil is correct in that the L3 events on Shanghai are shared across all
cores in a chip. I don't know if perfmon2 specifically traps for this; I
don't think it does. However the AMD documents suggest that by convention
only one core per chip should access these events. This suggestion isn'
Looks like Performance Counters for Linux (PCL) has made it into the 2.6.31
kernel tree:
http://lwn.net/Articles/339361/
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in
No, but someone on the permon2 list probably does.
- d
_
From: Stojan Bacev [mailto:stojanba...@yahoo.com]
Sent: Tuesday, August 11, 2009 6:26 PM
To: Dan Terpstra
Subject: Papi installation question with perfmon2 patch
Dan,
Thanks for the reply. I tried installing the perfmon2
Yup. The performance community started calling it PCL for shorthand, but the
kernel guys are generally referring to it as perf_counters.
- d
> -Original Message-
> From: Drongowski, Paul [mailto:paul.drongow...@amd.com]
> Sent: Tuesday, September 15, 2009 3:49 PM
> To: Godmar Back
> Cc: pe
Interestingly, there's a guy at ZIH Dresden who implemented a PAPI-C
component specifically to measure events on the uncore. He never tried to
measure both per-thread and uncore at the same time, and I doubt that it
would work, but found it intriguing that he was able to get reasonable data.
Like t
Gary -
As of *today* PAPI cannot count flops with Nehalem and perf_events. We're
fairly confident that this is a PAPI problem, not a perf_events problem, but
it's still a problem. We're working to fix this, but it indicates that
things are still in a state of flux...
- d
> -Original Message---
Stephane -
I imported the latest sources from libpfm the other day in preparation for
the PAPI-C release. Today our regression tests showed 0 counts for
PAPI_FP_OPS. In tracing this problem we discovered that the latest
intel_corei7_events.h has a whole bunch of new PFMLIB_NHM_UMASK_NCOMBO flags
s
Stephane Eranian [mailto:eran...@google.com]
> Sent: Thursday, January 14, 2010 5:18 PM
> To: Dan Terpstra
> Cc: perfmon2-devel@lists.sourceforge.net; jag...@eecs.utk.edu
> Subject: Re: Nehalem and PFMLIB_NHM_UMASK_NCOMBO
>
> Dan,
>
> I made that change recently because I learned
Stephane -
> -Original Message-
> From: Stephane Eranian [mailto:eran...@google.com]
> Sent: Friday, January 15, 2010 2:42 AM
> To: Dan Terpstra
> Cc: perfmon2-devel@lists.sourceforge.net; jag...@eecs.utk.edu
> Subject: Re: Nehalem and PFMLIB_NHM_UMASK_NCOMBO
>
>
Stephane -
How was this confirmed? Was it in documentation or by example? We can burn
two counters to implement this, but I'd really rather not :(
- d
> -Original Message-
> From: Stephane Eranian [mailto:eran...@google.com]
> Sent: Friday, January 15, 2010 5:22 PM
> To:
Excellent!
Now I'd love to see equivalent functionality on Nehalem!
- dan
> -Original Message-
> From: Stephane Eranian [mailto:eran...@google.com]
> Sent: Friday, January 22, 2010 5:43 AM
> To: linux-ker...@vger.kernel.org
> Cc: perfmon2-de...@lists.sf.net; eran...@gmail.com; pet...@infra
Why do you need to install swig?
If we have no intention to use a scripting language for libpfm4, should it be
required that a default build have swig? This seems like an unnecessary
constraint placed on the build environment. I'd rather see the python stuff
built optionally with a command line
We oughta at least link to it from somewhere on the PAPI page!
- d
On Jul 12, 2011, at 9:11 PM, Corey Ashford wrote:
> On 07/12/2011 11:20 AM, Vince Weaver wrote:
>> On Thu, 7 Jul 2011, Corey Ashford wrote:
>>>
>>> You can do event-based sampling with perf_events as well, but it's not
>>> trivia
Is this a candidate for resurrecting our patching protocol?
It'll only affect IvyBridge users with the new libpfm4.3, but that's becoming
an increasingly large subset.
I suppose the patch could include libpfm4.3, but that'd make it pretty bulky :)
- d
On Aug 31, 2012, at 2:19 PM, Vince Weaver wro
I've committed a fix for these naming changes but haven't tested it because we
don't have an Ivy Bridge.
Will, pull from git and give it a spin on an Ivy when you get a chance.
Thanks,
- d
On Aug 31, 2012, at 2:19 PM, Vince Weaver wrote:
> On Thu, 30 Aug 2012, William Cohen wrote:
>
>> Running
:
> On 09/06/2012 04:56 PM, Dan Terpstra wrote:
>> I've committed a fix for these naming changes but haven't tested it because
>> we don't have an Ivy Bridge.
>> Will, pull from git and give it a spin on an Ivy when you get a chance.
>> Thanks,
>> - d
>
51 matches
Mail list logo