Re: [perfmon2] Problems encountered on Pentium 4

2008-04-01 Thread Dan Terpstra
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 >

Re: [perfmon2] libpfm syscall patch

2008-04-03 Thread Dan Terpstra
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

Re: [perfmon2] libpfm syscall patch

2008-04-03 Thread Dan Terpstra
---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

[perfmon2] perfmon2 on Cell

2008-06-06 Thread Dan Terpstra
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

Re: [perfmon2] perfmon2 on Cell

2008-06-09 Thread Dan Terpstra
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 &

Re: [perfmon2] perfmon2 on Cell

2008-06-09 Thread Dan Terpstra
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

Re: [perfmon2] perfmon2 on Cell

2008-06-09 Thread Dan Terpstra
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

Re: [perfmon2] perfmon2 on Cell

2008-06-10 Thread Dan Terpstra
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

[perfmon2] CYCLES overflow on perfmon2 on Cell

2008-06-12 Thread Dan Terpstra
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. ---

Re: [perfmon2] CYCLES overflow on perfmon2 on Cell

2008-06-12 Thread Dan Terpstra
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

Re: [perfmon2] CYCLES overflow on perfmon2 on Cell

2008-06-12 Thread Dan Terpstra
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 >

Re: [perfmon2] CYCLES overflow on perfmon2 on Cell

2008-06-13 Thread Dan Terpstra
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, >

Re: [perfmon2] perfmon2 on Cell

2008-06-13 Thread Dan Terpstra
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

Re: [perfmon2] trouble installing pfmon...

2008-07-18 Thread Dan Terpstra
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

Re: [perfmon2] [PATCH] Identifying Pentium M processors

2008-08-12 Thread Dan Terpstra
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

Re: [perfmon2] pfm_delete_evtsets() going away in v3

2008-09-03 Thread Dan Terpstra
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

Re: [perfmon2] pfm_delete_evtsets() going away in v3

2008-09-08 Thread Dan Terpstra
> -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

Re: [perfmon2] [Ptools-perfapi] PAPI 3.6.2

2008-09-22 Thread Dan Terpstra
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

Re: [perfmon2] [Ptools-perfapi] Intel Hapertown support

2008-10-29 Thread Dan Terpstra
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

Re: [perfmon2] [Ptools-perfapi] Intel Hapertown support

2008-10-29 Thread Dan Terpstra
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

Re: [perfmon2] [Ptools-perfapi] Support for Intel Nehalem ??

2008-10-29 Thread Dan Terpstra
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

Re: [perfmon2] Intel Core i7 specs available.

2008-11-27 Thread Dan Terpstra
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

Re: [perfmon2] Intel Core i7 specs available.

2008-12-01 Thread Dan Terpstra
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

Re: [perfmon2] Intel Core i7 specs available.

2008-12-02 Thread Dan Terpstra
> -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

Re: [perfmon2] Intel Core i7 specs available.

2008-12-02 Thread Dan Terpstra
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

Re: [perfmon2] Intel Core i7 specs available.

2008-12-02 Thread Dan Terpstra
> -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

Re: [perfmon2] [patch 0/3] [Announcement] Performance Counters forLinux

2008-12-07 Thread Dan Terpstra
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

Re: [perfmon2] [Perfctr-devel] LWN article on performance counters - perfmon3 and "perf_counter_open" (not Mikael's perfctr?)

2008-12-09 Thread Dan Terpstra
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

Re: [perfmon2] Intel Nehalem support

2009-01-13 Thread Dan Terpstra
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

[perfmon2] Opteron patch problems

2009-01-14 Thread Dan Terpstra
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:

Re: [perfmon2] [Ptools-perfapi] how to count flops withoutPAPI_FP_OPS

2009-03-23 Thread Dan Terpstra
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

Re: [perfmon2] libpfm redesign

2009-06-04 Thread Dan Terpstra
> > 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

Re: [perfmon2] libpfm4 progress

2009-06-19 Thread Dan Terpstra
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..

Re: [perfmon2] libpfm4 progress

2009-06-19 Thread Dan Terpstra
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

Re: [perfmon2] libpfm4 progress

2009-06-19 Thread 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

Re: [perfmon2] [Ptools-perfapi] PAPI_L3_TCM error with threads

2009-07-06 Thread Dan Terpstra
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'

[perfmon2] PCL in the tree

2009-07-16 Thread Dan Terpstra
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

Re: [perfmon2] Papi installation question with perfmon2 patch

2009-08-11 Thread Dan Terpstra
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

Re: [perfmon2] questions about perfmon2

2009-09-15 Thread Dan Terpstra
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

Re: [perfmon2] Monitoring core and uncore events in the same testrun.

2009-09-23 Thread Dan Terpstra
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

Re: [perfmon2] Perfmon with a 2.6.31 kernel ???

2009-10-22 Thread Dan Terpstra
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---

[perfmon2] Nehalem and PFMLIB_NHM_UMASK_NCOMBO

2010-01-14 Thread Dan Terpstra
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

Re: [perfmon2] Nehalem and PFMLIB_NHM_UMASK_NCOMBO

2010-01-14 Thread Dan Terpstra
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

Re: [perfmon2] Nehalem and PFMLIB_NHM_UMASK_NCOMBO

2010-01-15 Thread Dan Terpstra
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 > >

Re: [perfmon2] Nehalem and PFMLIB_NHM_UMASK_NCOMBO

2010-01-15 Thread Dan Terpstra
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:

Re: [perfmon2] [PATCH] perf_events: AMD event scheduling (v1)

2010-01-22 Thread Dan Terpstra
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

Re: [perfmon2] libpfm4 build problem - straight out of git repo

2010-06-24 Thread Dan Terpstra
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

Re: [perfmon2] performance monitoring setting

2011-07-13 Thread Dan Terpstra
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

Re: [perfmon2] [Perfapi-devel] Event name differences between Intel Sandy Bridge and Ivy Bridge

2012-08-31 Thread Dan Terpstra
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

Re: [perfmon2] [Perfapi-devel] Event name differences between Intel Sandy Bridge and Ivy Bridge

2012-09-06 Thread Dan Terpstra
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

Re: [perfmon2] [Perfapi-devel] Event name differences between Intel Sandy Bridge and Ivy Bridge

2012-09-09 Thread Dan Terpstra
: > 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 >