You can subscribe to this list here.
2004 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(6) |
May
|
Jun
(4) |
Jul
(3) |
Aug
|
Sep
|
Oct
(2) |
Nov
(12) |
Dec
(10) |
2006 |
Jan
(27) |
Feb
(4) |
Mar
(3) |
Apr
(5) |
May
(5) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(7) |
Oct
(5) |
Nov
(11) |
Dec
(5) |
2007 |
Jan
(15) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2008 |
Jan
(7) |
Feb
(9) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(6) |
Jul
(2) |
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(1) |
2009 |
Jan
(11) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(8) |
Jun
(11) |
Jul
(9) |
Aug
(12) |
Sep
(1) |
Oct
(3) |
Nov
(10) |
Dec
|
2010 |
Jan
(3) |
Feb
(1) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
From: Rui L. <ru...@il...> - 2015-10-16 13:41:42
|
Hi Nilton, Thanks a lot for letting me know, and glad that it works for you! :-) Copying the list for archiving purposes... Thanks, Rui On 10/15/2015 05:36 PM, Nilton Luiz Queiroz Junior wrote: > Hello Rui, > I'm sorry for disturbing you, but i dont see that the rapl component was disabled. > > I just enable the component, and it worked. > > Thanks for help me, > and sorry for the inconvenience. > > Nilton > > > > Subject: Re: [PerfSuite-users] Error running psrun with papi rapl component > > To: nil...@ho... > > From: ru...@il... > > Date: Thu, 15 Oct 2015 11:46:45 -0500 > > > > Hi Nilton, > > > > Sorry for the delay in replying, and sorry you might have received two emails, where in the first one I forgot to attach a file and canceled it while sending. > > > > First a few questions: > > 1. Is it correct that your PerfSuite installation works with regular CPU events, and this issue is just for RAPL events? > > 2. What if you put only 1 RAPL event in your event config file? > > 3. What if you put a PAPI_TOT_CYC and 1 RAPL event in your event config file? > > > > PerfSuite does a dry run before actually running the program and in your case, the error was in the dry run part. From the source code, the problem was after calling PAPI_add_events(...) in do_dryrun() in src/libpshwpc/hwpc-papi.c. It looked like PAPI_add_events(...) did not return PAPI_OK, but the code handled only the error case of PAPI_ECNFLCT (counter conflict, i.e., they can not be measured without multiplexing) and the case where events were partially added. > > > > I added a few lines to print more debug info in the hwpc-papi.c file. Could you please replace the original one in src/libpshwpc/, then do a rebuild, re-install and re-run, and let me know the output? > > > > Sorry now I don't have a machine which supports RAPL events and allows me the root access, so I can not debug/test further. > > > > Thanks, > > Rui > > > > On 10/13/2015 02:59 PM, Nilton Luiz Queiroz Junior wrote: > > > Hello, i was trying to run a program with rapl component and got the following error: > > > > > > "libpsrun fatal error: error reported by performance software layer" > > > > > > then i recompile perfsuit with debug, and set the PS_DEBUG enviroment variable with value 3 > > > > > > i ran again and got the following error: > > > > > > PerfSuite debugging enabled (debug level: PS_DEBUG_INFO) [PID 20980] > > > Library version: threaded > > > [PID 20980] Environment (entry of psrun_init) > > > [PID 20980] PSRUN_DOFORK = (null) > > > [PID 20980] LD_PRELOAD = libpsrun.so.0 > > > [PID 20980] PSRUN_PID = 20980 > > > [PID 20980] PS_HWPC_FILE = energy.out.stats > > > libpsrun.c:201 : [PID 20980] entering psrun_init > > > libpsrun.c:304 : [PID 20980]: unsetting LD_PRELOAD > > > hwpc.c:301 : Initializing real time clock... > > > timers.c:416 : Using timestamp counter for RTC. > > > cpuid-x86.c:134 : Retrieving max CPUID function and vendor string... > > > cpuid-x86.c:114 : d 756e6547 6c65746e 49656e69 > > > cpuid-x86.c:149 : Vendor identified as Intel (GenuineIntel) > > > cpuid-x86.c:190 : Retrieving processor signature... > > > cpuid-x86.c:114 : 306a9 7100800 7fbae3ff bfebfbff > > > cpuid-x86.c:222 : eax = 306a9, ebx=7100800 > > > cpuid-x86.c:226 : family=6, model=58, stepping=9. > > > cpuid-x86.c:235 : Checking for implementation of brand string... > > > cpuid-x86.c:114 : 80000008 0 0 0 > > > cpuid-x86.c:114 : 20202020 20202020 65746e49 2952286c > > > cpuid-x86.c:114 : 726f4320 4d542865 37692029 3737332d > > > cpuid-x86.c:114 : 50432030 20402055 30342e33 7a4847 > > > cpuid-x86.c:267 : Brand string is available > > > cpuid-x86.c:283 : Checking deterministic cache parameters... > > > cpuid-x86.c:114 : 1c004121 1c0003f 3f 0 > > > cpuid-x86.c:114 : 1c004122 1c0003f 3f 0 > > > cpuid-x86.c:114 : 1c004143 1c0003f 1ff 0 > > > cpuid-x86.c:114 : 1c03c163 3c0003f 1fff 6 > > > cpuid-x86.c:114 : 0 0 0 0 > > > cpuid-x86.c:292 : No more caches (iteration 4) > > > cpuid-x86.c:356 : Retrieving cache information... > > > cpuid-x86.c:114 : 76035a01 f0b2ff 0 ca0000 > > > cpuid-x86.c:364 : Need to run CPUID 0 more times to get cache info > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 5a > > > cpuid-x86.c:404 : Cache regval = 3 > > > cpuid-x86.c:404 : Cache regval = 76 > > > cpuid-x86.c:404 : Cache regval = ff > > > cpuid-x86.c:1399 : CPUID reports that leaf 2 lacks cache info > > > cpuid-x86.c:404 : Cache regval = b2 > > > cpuid-x86.c:404 : Cache regval = f0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor f0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = ca > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > hwpc.c:311 : Initialized global data > > > hwpc.c:320 : Signal handling off. > > > dyn-conf.c:86 : arch=0, family=6, model=58, stepping=9, extra=-1. > > > hwpc.c:2389 : Configuration file set to rapl.xml > > > hwpc.c:2434 : Attempting to parse "rapl.xml" > > > xmlparse.c:305 : XML parser: parsing expected XML document element ps_hwpc_eventlist (class = "PAPI") > > > xmlparse.c:494 : XML parser: found 3 events: > > > rapl::RAPL_ENERGY_CORES > > > rapl::RAPL_ENERGY_PKG > > > rapl::RAPL_ENERGY_GPU > > > hwpc.c:334 : Configuration file read > > > hwpc.c:336 : Read 3 events > > > hwpc.c:2259 : Initializing PAPI class... > > > hwpc-papi.c:343 : PAPI initialized successfully > > > hwpc-papi.c:362 : event 'rapl::RAPL_ENERGY_CORES', component index 1. > > > hwpc-papi.c:372 : PAPI_MAX_MPX_CTRS = 128. > > > hwpc.c:365 : Performance software supports 128 events max. > > > hwpc.c:458 : Calling package init routine > > > hwpc-papi.c:409 : PAPI initialized successfully > > > hwpc-papi.c:431 : PAPI version in use: 5.4.1.0 > > > hwpc-papi.c:557 : Available counters: 11 > > > Events requested: 3 > > > Derived events: 0 > > > hwpc-papi.c:1063 : Starting dry run check of event set. > > > hwpc-papi.c:1076 : Created dry run non-mpx event set successfully. > > > hwpc-papi.c:1229 : Dry run PAPI_start failed != ECNFLCT (Invalid argument). > > > hwpc-papi.c:603 : Dry run mpx check failed. > > > libpsrun fatal error: error reported by performance software layer > > > root@lcp-u2:/home/anderson/gerar_bases/benchs# psrun -r -F text -c rapl.xml -o energy.out.stats ./bubblesort > > > PerfSuite debugging enabled (debug level: PS_DEBUG_INFO) [PID 20996] > > > Library version: threaded > > > [PID 20996] Environment (entry of psrun_init) > > > [PID 20996] PSRUN_DOFORK = (null) > > > [PID 20996] LD_PRELOAD = libpsrun.so.0 > > > [PID 20996] PSRUN_PID = 20996 > > > [PID 20996] PS_HWPC_FILE = energy.out.stats > > > libpsrun.c:201 : [PID 20996] entering psrun_init > > > libpsrun.c:304 : [PID 20996]: unsetting LD_PRELOAD > > > hwpc.c:301 : Initializing real time clock... > > > timers.c:416 : Using timestamp counter for RTC. > > > cpuid-x86.c:134 : Retrieving max CPUID function and vendor string... > > > cpuid-x86.c:114 : d 756e6547 6c65746e 49656e69 > > > cpuid-x86.c:149 : Vendor identified as Intel (GenuineIntel) > > > cpuid-x86.c:190 : Retrieving processor signature... > > > cpuid-x86.c:114 : 306a9 1100800 7fbae3ff bfebfbff > > > cpuid-x86.c:222 : eax = 306a9, ebx=1100800 > > > cpuid-x86.c:226 : family=6, model=58, stepping=9. > > > cpuid-x86.c:235 : Checking for implementation of brand string... > > > cpuid-x86.c:114 : 80000008 0 0 0 > > > cpuid-x86.c:114 : 20202020 20202020 65746e49 2952286c > > > cpuid-x86.c:114 : 726f4320 4d542865 37692029 3737332d > > > cpuid-x86.c:114 : 50432030 20402055 30342e33 7a4847 > > > cpuid-x86.c:267 : Brand string is available > > > cpuid-x86.c:283 : Checking deterministic cache parameters... > > > cpuid-x86.c:114 : 1c004121 1c0003f 3f 0 > > > cpuid-x86.c:114 : 1c004122 1c0003f 3f 0 > > > cpuid-x86.c:114 : 1c004143 1c0003f 1ff 0 > > > cpuid-x86.c:114 : 1c03c163 3c0003f 1fff 6 > > > cpuid-x86.c:114 : 0 0 0 0 > > > cpuid-x86.c:292 : No more caches (iteration 4) > > > cpuid-x86.c:356 : Retrieving cache information... > > > cpuid-x86.c:114 : 76035a01 f0b2ff 0 ca0000 > > > cpuid-x86.c:364 : Need to run CPUID 0 more times to get cache info > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 5a > > > cpuid-x86.c:404 : Cache regval = 3 > > > cpuid-x86.c:404 : Cache regval = 76 > > > cpuid-x86.c:404 : Cache regval = ff > > > cpuid-x86.c:1399 : CPUID reports that leaf 2 lacks cache info > > > cpuid-x86.c:404 : Cache regval = b2 > > > cpuid-x86.c:404 : Cache regval = f0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor f0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > cpuid-x86.c:404 : Cache regval = ca > > > cpuid-x86.c:404 : Cache regval = 0 > > > cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 > > > hwpc.c:311 : Initialized global data > > > hwpc.c:320 : Signal handling off. > > > dyn-conf.c:86 : arch=0, family=6, model=58, stepping=9, extra=-1. > > > hwpc.c:2389 : Configuration file set to rapl.xml > > > hwpc.c:2434 : Attempting to parse "rapl.xml" > > > xmlparse.c:305 : XML parser: parsing expected XML document element ps_hwpc_eventlist (class = "PAPI") > > > xmlparse.c:494 : XML parser: found 3 events: > > > rapl::RAPL_ENERGY_CORES > > > rapl::RAPL_ENERGY_PKG > > > rapl::RAPL_ENERGY_GPU > > > hwpc.c:334 : Configuration file read > > > hwpc.c:336 : Read 3 events > > > hwpc.c:2259 : Initializing PAPI class... > > > hwpc-papi.c:343 : PAPI initialized successfully > > > hwpc-papi.c:362 : event 'rapl::RAPL_ENERGY_CORES', component index 1. > > > hwpc-papi.c:372 : PAPI_MAX_MPX_CTRS = 128. > > > hwpc.c:365 : Performance software supports 128 events max. > > > hwpc.c:458 : Calling package init routine > > > hwpc-papi.c:409 : PAPI initialized successfully > > > hwpc-papi.c:431 : PAPI version in use: 5.4.1.0 > > > hwpc-papi.c:557 : Available counters: 11 > > > Events requested: 3 > > > Derived events: 0 > > > hwpc-papi.c:1063 : Starting dry run check of event set. > > > hwpc-papi.c:1076 : Created dry run non-mpx event set successfully. > > > hwpc-papi.c:1229 : Dry run PAPI_start failed != ECNFLCT (Invalid argument). > > > hwpc-papi.c:603 : Dry run mpx check failed. > > > libpsrun fatal error: error reported by performance software layer > > > > > > > > > ps: i'm using PAPI version 5.4.1 and perfsuite 1.1.4 and as root (because the rapl events only works with root user) in a linux kernel 3.16.0-41-generic (ubuntu 14.10) > > > > > > > > > Nilton > > > > > > > > > ------------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > PerfSuite-users mailing list > > > Per...@li... > > > https://lists.sourceforge.net/lists/listinfo/perfsuite-users > > > |
From: Nilton L. Q. J. <nil...@ho...> - 2015-10-13 19:59:09
|
Hello, i was trying to run a program with rapl component and got the following error: "libpsrun fatal error: error reported by performance software layer" then i recompile perfsuit with debug, and set the PS_DEBUG enviroment variable with value 3 i ran again and got the following error: PerfSuite debugging enabled (debug level: PS_DEBUG_INFO) [PID 20980] Library version: threaded [PID 20980] Environment (entry of psrun_init) [PID 20980] PSRUN_DOFORK = (null) [PID 20980] LD_PRELOAD = libpsrun.so.0 [PID 20980] PSRUN_PID = 20980 [PID 20980] PS_HWPC_FILE = energy.out.stats libpsrun.c:201 : [PID 20980] entering psrun_init libpsrun.c:304 : [PID 20980]: unsetting LD_PRELOAD hwpc.c:301 : Initializing real time clock... timers.c:416 : Using timestamp counter for RTC. cpuid-x86.c:134 : Retrieving max CPUID function and vendor string... cpuid-x86.c:114 : d 756e6547 6c65746e 49656e69 cpuid-x86.c:149 : Vendor identified as Intel (GenuineIntel) cpuid-x86.c:190 : Retrieving processor signature... cpuid-x86.c:114 : 306a9 7100800 7fbae3ff bfebfbff cpuid-x86.c:222 : eax = 306a9, ebx=7100800 cpuid-x86.c:226 : family=6, model=58, stepping=9. cpuid-x86.c:235 : Checking for implementation of brand string... cpuid-x86.c:114 : 80000008 0 0 0 cpuid-x86.c:114 : 20202020 20202020 65746e49 2952286c cpuid-x86.c:114 : 726f4320 4d542865 37692029 3737332d cpuid-x86.c:114 : 50432030 20402055 30342e33 7a4847 cpuid-x86.c:267 : Brand string is available cpuid-x86.c:283 : Checking deterministic cache parameters... cpuid-x86.c:114 : 1c004121 1c0003f 3f 0 cpuid-x86.c:114 : 1c004122 1c0003f 3f 0 cpuid-x86.c:114 : 1c004143 1c0003f 1ff 0 cpuid-x86.c:114 : 1c03c163 3c0003f 1fff 6 cpuid-x86.c:114 : 0 0 0 0 cpuid-x86.c:292 : No more caches (iteration 4) cpuid-x86.c:356 : Retrieving cache information... cpuid-x86.c:114 : 76035a01 f0b2ff 0 ca0000 cpuid-x86.c:364 : Need to run CPUID 0 more times to get cache info cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 5a cpuid-x86.c:404 : Cache regval = 3 cpuid-x86.c:404 : Cache regval = 76 cpuid-x86.c:404 : Cache regval = ff cpuid-x86.c:1399 : CPUID reports that leaf 2 lacks cache info cpuid-x86.c:404 : Cache regval = b2 cpuid-x86.c:404 : Cache regval = f0 cpuid-x86.c:422 : Skipping cache alloc for descriptor f0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = ca cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 hwpc.c:311 : Initialized global data hwpc.c:320 : Signal handling off. dyn-conf.c:86 : arch=0, family=6, model=58, stepping=9, extra=-1. hwpc.c:2389 : Configuration file set to rapl.xml hwpc.c:2434 : Attempting to parse "rapl.xml" xmlparse.c:305 : XML parser: parsing expected XML document element ps_hwpc_eventlist (class = "PAPI") xmlparse.c:494 : XML parser: found 3 events: rapl::RAPL_ENERGY_CORES rapl::RAPL_ENERGY_PKG rapl::RAPL_ENERGY_GPU hwpc.c:334 : Configuration file read hwpc.c:336 : Read 3 events hwpc.c:2259 : Initializing PAPI class... hwpc-papi.c:343 : PAPI initialized successfully hwpc-papi.c:362 : event 'rapl::RAPL_ENERGY_CORES', component index 1. hwpc-papi.c:372 : PAPI_MAX_MPX_CTRS = 128. hwpc.c:365 : Performance software supports 128 events max. hwpc.c:458 : Calling package init routine hwpc-papi.c:409 : PAPI initialized successfully hwpc-papi.c:431 : PAPI version in use: 5.4.1.0 hwpc-papi.c:557 : Available counters: 11 Events requested: 3 Derived events: 0 hwpc-papi.c:1063 : Starting dry run check of event set. hwpc-papi.c:1076 : Created dry run non-mpx event set successfully. hwpc-papi.c:1229 : Dry run PAPI_start failed != ECNFLCT (Invalid argument). hwpc-papi.c:603 : Dry run mpx check failed. libpsrun fatal error: error reported by performance software layer root@lcp-u2:/home/anderson/gerar_bases/benchs# psrun -r -F text -c rapl.xml -o energy.out.stats ./bubblesort PerfSuite debugging enabled (debug level: PS_DEBUG_INFO) [PID 20996] Library version: threaded [PID 20996] Environment (entry of psrun_init) [PID 20996] PSRUN_DOFORK = (null) [PID 20996] LD_PRELOAD = libpsrun.so.0 [PID 20996] PSRUN_PID = 20996 [PID 20996] PS_HWPC_FILE = energy.out.stats libpsrun.c:201 : [PID 20996] entering psrun_init libpsrun.c:304 : [PID 20996]: unsetting LD_PRELOAD hwpc.c:301 : Initializing real time clock... timers.c:416 : Using timestamp counter for RTC. cpuid-x86.c:134 : Retrieving max CPUID function and vendor string... cpuid-x86.c:114 : d 756e6547 6c65746e 49656e69 cpuid-x86.c:149 : Vendor identified as Intel (GenuineIntel) cpuid-x86.c:190 : Retrieving processor signature... cpuid-x86.c:114 : 306a9 1100800 7fbae3ff bfebfbff cpuid-x86.c:222 : eax = 306a9, ebx=1100800 cpuid-x86.c:226 : family=6, model=58, stepping=9. cpuid-x86.c:235 : Checking for implementation of brand string... cpuid-x86.c:114 : 80000008 0 0 0 cpuid-x86.c:114 : 20202020 20202020 65746e49 2952286c cpuid-x86.c:114 : 726f4320 4d542865 37692029 3737332d cpuid-x86.c:114 : 50432030 20402055 30342e33 7a4847 cpuid-x86.c:267 : Brand string is available cpuid-x86.c:283 : Checking deterministic cache parameters... cpuid-x86.c:114 : 1c004121 1c0003f 3f 0 cpuid-x86.c:114 : 1c004122 1c0003f 3f 0 cpuid-x86.c:114 : 1c004143 1c0003f 1ff 0 cpuid-x86.c:114 : 1c03c163 3c0003f 1fff 6 cpuid-x86.c:114 : 0 0 0 0 cpuid-x86.c:292 : No more caches (iteration 4) cpuid-x86.c:356 : Retrieving cache information... cpuid-x86.c:114 : 76035a01 f0b2ff 0 ca0000 cpuid-x86.c:364 : Need to run CPUID 0 more times to get cache info cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 5a cpuid-x86.c:404 : Cache regval = 3 cpuid-x86.c:404 : Cache regval = 76 cpuid-x86.c:404 : Cache regval = ff cpuid-x86.c:1399 : CPUID reports that leaf 2 lacks cache info cpuid-x86.c:404 : Cache regval = b2 cpuid-x86.c:404 : Cache regval = f0 cpuid-x86.c:422 : Skipping cache alloc for descriptor f0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 cpuid-x86.c:404 : Cache regval = ca cpuid-x86.c:404 : Cache regval = 0 cpuid-x86.c:422 : Skipping cache alloc for descriptor 0 hwpc.c:311 : Initialized global data hwpc.c:320 : Signal handling off. dyn-conf.c:86 : arch=0, family=6, model=58, stepping=9, extra=-1. hwpc.c:2389 : Configuration file set to rapl.xml hwpc.c:2434 : Attempting to parse "rapl.xml" xmlparse.c:305 : XML parser: parsing expected XML document element ps_hwpc_eventlist (class = "PAPI") xmlparse.c:494 : XML parser: found 3 events: rapl::RAPL_ENERGY_CORES rapl::RAPL_ENERGY_PKG rapl::RAPL_ENERGY_GPU hwpc.c:334 : Configuration file read hwpc.c:336 : Read 3 events hwpc.c:2259 : Initializing PAPI class... hwpc-papi.c:343 : PAPI initialized successfully hwpc-papi.c:362 : event 'rapl::RAPL_ENERGY_CORES', component index 1. hwpc-papi.c:372 : PAPI_MAX_MPX_CTRS = 128. hwpc.c:365 : Performance software supports 128 events max. hwpc.c:458 : Calling package init routine hwpc-papi.c:409 : PAPI initialized successfully hwpc-papi.c:431 : PAPI version in use: 5.4.1.0 hwpc-papi.c:557 : Available counters: 11 Events requested: 3 Derived events: 0 hwpc-papi.c:1063 : Starting dry run check of event set. hwpc-papi.c:1076 : Created dry run non-mpx event set successfully. hwpc-papi.c:1229 : Dry run PAPI_start failed != ECNFLCT (Invalid argument). hwpc-papi.c:603 : Dry run mpx check failed. libpsrun fatal error: error reported by performance software layer ps: i'm using PAPI version 5.4.1 and perfsuite 1.1.4 and as root (because the rapl events only works with root user) in a linux kernel 3.16.0-41-generic (ubuntu 14.10) Nilton |
From: Rui L. <ru...@il...> - 2015-07-24 17:26:50
|
Hi JG, Thanks a lot for sharing your finding and solution with the list! Sorry only today I was able to forward it to the list: I was on vacation until July 14, then the sourceforge list server was down for a few days, then I mistakenly handled the moderation of this mail. Thanks, Rui -------- Forwarded Message -------- Subject: perfsuite/1.1.4 on Cray/XC30 Date: Mon, 1 Jun 2015 14:25:09 +0200 From: jgp <jg...@cs...> To: per...@li... CC: jg...@cs... Hi, I am testing perfsuite/1.1.4 on Cray/XC (PizDaint) and i noticed an issue with papi. It looks like that if i configure perfsuite with --with-papi=/opt/cray/papi/5.4.0.1, psrun psrun will fail with: Error 101 for CUDA Driver API function 'cuCtxCreate'. cuptiQuery failed even if i do not use cuda at all in my code. Solution is to use a papi compiled without cudatoolkit then psrun will run fine, as you can see here: https://bitbucket.org/jgphpc/pug/issue/29/perfsuite-bluewaters (look for Cupti issue). I am wondering if you experience the same issue on your XK ? Regards, jg. |
From: Rui L. <ru...@il...> - 2014-09-03 14:36:29
|
Hi Nilton, Thanks a lot for letting me know! Glad to know it worked for you. :-) Copying the user mailing list for archival purposes... Best wishes, Rui On 09/02/2014 07:03 PM, Nilton Luiz Queiroz Junior wrote: > Hi Rui, > > now worked, > > I'm grateful for your help. > Thanks A LOT! > > Nilton > > > > Date: Tue, 2 Sep 2014 17:59:28 -0500 > > From: ru...@il... > > To: nil...@ho... > > Subject: Re: Error Installing > > > > Hi Nilton, > > > > Thanks a lot for your prompt reply! > > > > It seemed that the Fortran compiler on your system -- /usr/bin/f77, which returns in "-v" output as "fort77 Version 1.15" -- had issues compiling some tests. We can use the "F77" environment variable to try a different Fortran compiler that's available on your system. > > > > Also you did not enable Java -- currently we recommend a user to build the Java version of the psprocess tool, instead of the old Tcl version. We can do this by using the "--enable-java" option. > > > > Could you please try: > > ./configure --with-papi --enable-java F77=<another_Fortran_compiler> > > and let me know of the result? For example, if you have the GNU Fortran compiler (gfortran), then do: > > ./configure --with-papi --enable-java F77=gfortran > > > > Again, if there's any error, please provide the "config.log" file with your email. Thanks a lot! > > > > Thanks, > > Rui > > > > On 09/02/2014 03:41 PM, Nilton Luiz Queiroz Junior wrote: > > > Hi Rui, the config.log is attached in this e-mail. > > > > > > Thanks for help, > > > Nilton. > > > > > > > > > > Date: Tue, 2 Sep 2014 14:40:39 -0500 > > > > From: ru...@il... > > > > To: nil...@ho... > > > > Subject: Re: Error Installing > > > > > > > > Hi Nilton Luiz Queiroz, > > > > > > > > Thanks for your interest in using PerfSuite! > > > > > > > > This is Rui Liu, the current maintainer of PerfSuite. Could you please provide the entire "config.log" file that was generated when you ran "./configure ...", to help diagnose the problem? Thanks a lot! > > > > > > > > Thanks, > > > > Rui > > > > > > > > On 09/02/2014 01:02 PM, Nilton Luiz Queiroz Junior wrote: > > > > > after run "./configure --with-papi" i try run make, but i've the following error message: > > > > > > > > > > Making all in tests > > > > > f77 -I../../../src/libperfsuite -g -O2 -c -o psf_rtc-test.o psf_rtc-test.f > > > > > MAIN rtctest: > > > > > dowork: > > > > > psf_rtc-test.f: In function ‘MAIN__’: > > > > > psf_rtc-test.f:75:5: error: unknown type name ‘longint’ > > > > > psf_rtc-test.f:79:5: error: unknown type name ‘longint’ > > > > > psf_rtc-test.f:81:43: error: unknown type name ‘longint’ > > > > > /usr/bin/f77: aborting compilation > > > > > make[4]: *** [psf_rtc-test.o] Error 25 > > > > > make[3]: *** [all-recursive] Error 1 > > > > > make[2]: *** [all-recursive] Error 1 > > > > > make[1]: *** [all-recursive] Error 1 > > > > > make: *** [all] Error 2 > > > > > > > > > > anyone could help me? > > > > > Thanks > > > > > --> |
From: Rui L. <ru...@il...> - 2013-12-20 23:34:48
|
PerfSuite 1.1.4 is now available. The only change in source code of this release compared with the previous one (1.1.3), is the following: - Removed a debug line that was mistakenly left. With it "psrun" always printed one line in standard output when starting a program: Event: '<event_name>', component index: <papi_comp_index>. such as: "Event: 'PAPI_BR_CN', component index: 0." Depending on your situation, you may or may not require this update. Sorry for my oversight while releasing the previous version and causing this trouble. URL: http://sourceforge.net/projects/perfsuite Happy Holidays to everyone! Thanks, Rui |
From: Rui L. <ru...@il...> - 2013-11-05 15:40:10
|
PerfSuite 1.1.3 is now available. The major highlights of this release are: - Added the support for PAPI non-CPU component events. - Added the feature to dynamically detect CPU type and set the default event configuration file at run time, instead of using the file determined at configure time. - Used the "papi2_any-null.xml", containing only the "PAPI_TOT_CYC" and "PAPI_TOT_INS", as the default config file, if the CPU family or model is unsupported, to avoid issues. Also used it as the default config file for IBM Power CPUs, if the pvr version is unsupported. - Removed the functionality in psinv that printed out features of x86 and x86-64 CPUs, since this functionality requires high maintenance, but seems rarely used. This release also contains other enhancements and bug fixes. A complete listing of changes can be found in the CHANGES file. URL: http://sourceforge.net/projects/perfsuite Thanks and enjoy, Rui |
From: Rui L. <ru...@il...> - 2013-10-17 14:38:16
|
Hi Phuong, Glad to know you succeeded in PerfSuite installation! Copying the list in case it could help others... Thanks, Rui On 10/16/2013 10:21 PM, Pham Thanh Phuong wrote: > Hi Rui Liu, > > I have just finished the installation of Perfsuite in my cluster. Thank you very much for your help. > > Best regards, > Phuong Pham > > > On 11 October 2013 22:11, Rui Liu <ru...@il... <mailto:ru...@il...>> wrote: > > Hi Phuong, > > Thanks a lot for providing the config.log file! It helped to locate the issue. > > Summary: it seemed that you had 2 PAPI installations on your system -- one at /usr, the other at /usr/local, however, you used "--with-papi=/usr/local/bin" as your PerfSuite configure option. > > Solution: remove one of the 2 PAPI installations, and use the correct config option, either "--with-papi=/usr" or "--with-papi=/usr/local", depending on which PAPI installation you keep. > > > To remove a PAPI installation, since it does not have an "uninstall" make target, in PAPI's installation root path, you can do a "ls" followed by "rm" to remove it: > ls bin/papi_* include/*papi.h include/papiStdEventDefs.h lib/libpapi.* lib/libpfm.* man/man1/papi_* man/man3/PAPI* share/papi (make sure these are all PAPI files) > rm -rf bin/papi_* include/*papi.h include/papiStdEventDefs.h lib/libpapi.* lib/libpfm.* man/man1/papi_* man/man3/PAPI* share/papi > Since your PAPI root path is "/usr" or "/usr/local", which is a system path, so be careful not to remove unintended files. That's why we do a "ls" first. :-) > > > > Details: > > > fpapitest.f: In program `fpapitest': > fpapitest.f:55: > include 'f77papi.h' > ^ > Unable to open INCLUDE file `f77papi.h' at (^) > > > [root@node5 perfsuite-1.1.2]# locate f77papi.h > /root/PerfSuit/papi-4.4.0/src/____f77papi.h > /usr/include/f77papi.h > /usr/local/include/f77papi.h > > > As you can see, the "f77papi.h" file is part of a PAPI installation. The "locate" result showed 3 locations: the first one was your PAPI source, the next 2 lines indicated that you installed PAPI twice, one in "/usr", the other in "/usr/local". However, you used "--with-papi=/usr/local/bin" in your PerfSuite configure option. The "config.log" showed that "configure" was using /usr/local/bin/include as PAPI include file path, and /usr/local/bin/lib as PAPI library path -- clearly it could not find the PAPI files there, however, it found the PAPI files of another installation in /usr/include and /usr/lib, since these are system paths. So this scenario fooled "configure" to think that PAPI was installed at "/usr/local/bin", and defined in "config.h" and "config.log" the following: > > PAPI_CPPFLAGS='-I/usr/local/__bin/include ' > ... > PAPI_LDFLAGS=' -L/usr/local/bin/lib' > PAPI_LIBDIR='/usr/local/bin/__lib' > PAPI_ROOTDIR='/usr/local/bin' > > Later on, the "Makefile.am"-generated "Makefile" used PAPI_CPPFLAGS in compiling fpapitest.f, and certainly could not find f77papi.h there to include. > > > Appended below are a few relevant lines in your "config.log" regarding "configure"'s checking of PAPI support. One can see that it was using "/usr/local/bin/include" and "/usr/local/bin/lib". > > > Thanks, > Rui > > > ------------------------------__------------------------------__------ > configure:22327: checking for PAPI support > configure:22354: checking papi.h usability > configure:22354: gcc -c -g -O2 -I/usr/local/bin/include conftest.c >&5 > configure:22354: $? = 0 > configure:22354: result: yes > configure:22354: checking papi.h presence > configure:22354: gcc -E -I/usr/local/bin/include conftest.c > configure:22354: $? = 0 > configure:22354: result: yes > configure:22354: checking for papi.h > configure:22354: result: yes > configure:22372: checking PAPI version > configure:22410: gcc -o conftest -g -O2 -I/usr/local/bin/include conftest.c >&5 > configure:22410: $? = 0 > configure:22410: ./conftest > configure:22410: $? = 0 > configure:22421: result: 4.4.0.0 > configure:22447: Using PAPI subdirectory "lib" > configure:22451: checking for library containing PAPI_library_init > configure:22490: gcc -o conftest -g -O2 -I/usr/local/bin/include -L/usr/local/bin/lib conftest.c >&5 > /tmp/cc4V1S70.o: In function `main': > /root/PerfSuit/perfsuite-1.1.__2/conftest.c:72: undefined reference to `PAPI_library_init' > collect2: ld returned 1 exit status > configure:22490: $? = 1 > configure: failed program was: > | /* confdefs.h */ > ... > configure:22490: gcc -o conftest -g -O2 -I/usr/local/bin/include -L/usr/local/bin/lib conftest.c -lpapi >&5 > configure:22490: $? = 0 > configure:22507: result: -lpapi > ------------------------------__------------------------------__------ > > > > > > On 10/10/2013 09:05 PM, Pham Thanh Phuong wrote: > > Hi Rui Liu, > > Here is the config.log file and I am trying to find out the origin of errors. > Thank you for your quickly reply, Thank you very much. > > Phuong > > > > On 10 October 2013 21:48, Rui Liu <ru...@il... <mailto:ru...@il...> <mailto:ru...@il... <mailto:ru...@il...>>> wrote: > > Hi Phuong, > > Thanks for your reply, and glad that you solved the Java config issue by yourself! :-) > > Regarding this issue, could you please send me the following: > 1) the "config.log" file in the PerfSuite's top source directory (where the "LICENSE", "INSTALL", "README" files are); > This file contains detailed info about the exact options you used in "configure", and typically is very helpful in debugging a config/make issue. > 2) In src/libpshwpc/tests/ (the directory containing "fpapitest.f"), the output of: > make clean > make > > Thanks a lot! > > Thanks, > Rui > > > On 10/10/2013 12:28 AM, Pham Thanh Phuong wrote: > > Hi Rui Liu, > > I pass the configuration step but there is an error when using make to compile Perfsuite : > > > fpapitest.f: In program `fpapitest': > fpapitest.f:55: > include 'f77papi.h' > ^ > Unable to open INCLUDE file `f77papi.h' at (^) > fpapitest.f:61: > papiret = PAPI_VER_CURRENT > ^ > Invalid declaration of or reference to symbol `papi_ver_current' at (^) [initially seen at (^)] > fpapitest.f:69: > if (papiret .ne. PAPI_OK) then > ^ > Invalid declaration of or reference to symbol `papi_ok' at (^) [initially seen at (^)] > fpapitest.f:86: > call PAPIF_set_domain(PAPI_DOM_____KERNEL, papiret) > > ^ > Invalid declaration of or reference to symbol `papi_dom_kernel' at (^) [initially seen at (^)] > fpapitest.f:92: > call PAPIF_add_event(eventset, PAPI_TOT_INS, papiret) > ^ > Invalid declaration of or reference to symbol `papi_tot_ins' at (^) [initially seen at (^)] > fpapitest.f:98: > call PAPIF_add_event(eventset, PAPI_TOT_CYC, papiret) > ^ > Invalid declaration of or reference to symbol `papi_tot_cyc' at (^) [initially seen at (^)] > make[4]: *** [fpapitest.o] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > > > It seems the program cannot find out the f77papi.h but I found this file in my machine : > > [root@node5 perfsuite-1.1.2]# locate f77papi.h > /root/PerfSuit/papi-4.4.0/src/____f77papi.h > > /usr/include/f77papi.h > /usr/local/include/f77papi.h > > > Do you know where do the error come from ? > > Thank you very much. > > Best regards, > Phuong > > > > > On 10 October 2013 11:11, Pham Thanh Phuong <ph...@gm... <mailto:ph...@gm...> <mailto:ph...@gm... <mailto:ph...@gm...>> <mailto:ph...@gm... <mailto:ph...@gm...> <mailto:ph...@gm... <mailto:ph...@gm...>>>> wrote: > > Hi Rui Liu, > > Thank you very much for your email but it does not work follow up on your instructions because I did the PATH assignment before. In this case, I remove the gcj from my cluster and it works. Thank you for reminding me about gcj, I could manage it now. I continue to install it on other nodes and I hope my cluster will work well with PerfSuite ! > > Best regards, > > Phuong > > > > On 9 October 2013 21:23, Rui Liu <ru...@il... <mailto:ru...@il...> <mailto:ru...@il... <mailto:ru...@il...>> <mailto:ru...@il... <mailto:ru...@il...> <mailto:ru...@il... <mailto:ru...@il...>>>> wrote: > > Hi Phuong, > > Thank you for your interest in using PerfSuite! > > I'm PerfSuite's current maintainer. I saw similar behaviors before. This was because the "configure" command did not find the "java" executable, and instead found GNU Java ("gcj"), and gcj could have issues with PerfSuite. It looked like you installed Java under /root/PerfSuit/jdk1.7.0_40. Please add that to you PATH, that is, do one of the following: > export PATH=/root/PerfSuit/jdk1.7.0_______40/bin:$PATH (for bash, sh) > setenv PATH /root/PerfSuit/jdk1.7.0_40/______bin:$PATH (for tcsh, csh) > > > then run "configure" again. Hopefully this time it could find the correct java, javac, javadoc and jar executables in your JDK 1.7. > > Please let me know how it goes, or if you have further questions. Thanks! > > Thanks, > Rui Liu > NCSA, UIUC > > > On 10/08/2013 11:55 PM, Pham Thanh Phuong wrote: > > Dear all, > > I have a problem when install Perfsuite : > > configure: configuring Java support > checking for java... /root/PerfSuit/jdk1.7.0_40/______bin/java > You have CLASSPATH /root/PerfSuit/jdk1.7.0_40/______lib, hope it is correct > > > checking for kaffe... no > checking for java... java > checking for uudecode... no > configure: WARNING: I have to compile Test.class from scratch > checking for gcj... gcj -C > checking if gcj -C works... yes > checking if java works... configure: error: The Java VM java failed (see config.log, check the CLASSPATH?) > > > I wonder that what is the right CLASSPATH for configuring Perfsuite. Are there anyone have experience with this problem, please let me know. Thank you very much ! > > > (If I don't assign the CLASSPATH, the error will : cannot find java include files ? So that the classpath for perfsuite is ... ? ) > > Phuong. > > > > > |
From: Rui L. <ru...@il...> - 2013-04-26 14:34:20
|
Forwarding to the list for archival purposes... Hopefully useful for other users. Thanks, Rui -------- Original Message -------- Subject: RE: [PerfSuite-users] psrun for daemon applications Date: Wed, 24 Apr 2013 19:46:01 +0000 From: Hassan, Ahmad <ahm...@sa...> To: Rui Liu <ru...@il...> Hi Rui, This works amazingly well. Thanks for providing the metrics.xml template. Kind Regards, Ahmad SAP -----Original Message----- From: Rui Liu [mailto:ru...@il...] Sent: 23 April 2013 21:53 To: Hassan, Ahmad Subject: Re: [PerfSuite-users] psrun for daemon applications Hi Ahmad, Thanks a lot for trying out different approaches and reporting the results! Glad to know it's getting closer. Now you are becoming an advanced user of PerfSuite. :-) > But the output is somewhat different from what I want. I am looking for aggregated values of all four attributes that are present in individual XML files so that I can calculate CPI, Total LLC misses and LLC accesses. > Any ideas? You can try the user metrics definition feature of psprocess. I created a user metrics def file for your goal and attached it. Then do: psprocess -b -M . -m metrics.xml combined.xml -o psout.txt The "metrics.xml" file contains the definitions of 5 customized metrics: CPI, the counts of PAPI_TOT_CYC, PAPI_TOT_INS, PAPI_L3_TCA, and PAPI_L3_TCM. In the 2nd half of the output -- "Aggregate Statistics", the last column, named "Sum", contains the sum of all the numbers for the metric in "combined.xml". The above will give you the total LLC misses and LLC accesses. For CPI, you'll have to manually divide the values of the PAPI_TOT_CYC "sum" by the PAPI_TOT_INS "sum". The CPI metric definition included in "metrics.xml" is just for illustration purpose. It calculates CPI for the particular XML file (in this case for the particular thread), so the sum of all of them probably does not make sense. :-) That's why I wrote in the above to manually calculate it using sum of PAPI_TOT_CYC/sum of PAPI_TOT_INS. And even when calculated that way, I'm unsure how useful it is, since each thread might be doing different things, some (such as the main) thread might be idling. But maybe in your case it could be useful, as a general indication of program behavior. The output of psprocess mixes the user metrics with the system ones, sorting them alphabetically by the descriptions. I used a prefix string "user- " for the user defined ones, so they appear together at the end. This is not required; it just made it easier to find them in the output. Examine the attached "metrics.xml" file and the PerfSuite system default one for PAPI at $PREFIX/share/perfsuite/xml/pshwpc/PAPI_metrics.xml, and you will understand the syntax. Then you can customize it to your needs. Thanks, Rui On 04/23/2013 12:34 PM, Hassan, Ahmad wrote: > Hi Rui, > > Okay I have tried psprocess utility on a various xml files as follows: > > The individual xml files have following four fields: > <hwpcevent type="preset" name="PAPI_TOT_CYC" derived="no">127709818</hwpcevent> > <hwpcevent type="preset" name="PAPI_TOT_INS" derived="no">162427885</hwpcevent> > <hwpcevent type="preset" name="PAPI_L3_DCA" derived="yes">734563</hwpcevent> > <hwpcevent type="preset" name="PAPI_L3_TCM" derived="no">303576</hwpcevent> > > psprocess -c *.xml -o combined.xml > psprocess -b combined.xml -o psout.txt > > But the output is somewhat different from what I want. I am looking for aggregated values of all four attributes that are present in individual XML files so that I can calculate CPI, Total LLC misses and LLC accesses. > > Any ideas? > > Kind Regards, Ahmad > SAP > > -----Original Message----- > From: Rui Liu [mailto:ru...@il...] > Sent: 23 April 2013 15:36 > To: Hassan, Ahmad > Subject: Re: [PerfSuite-users] psrun for daemon applications > > Hi Ahmad, > > Glad to know that XML files are generated now. :-) > >> ... I ran few benchmarks on a 10G dataset and queries touch around 2G of data but the numbers that I am getting from psrun are very small. In addition to that, the number are more or less same for all queries and for different dataset sizes. This gives me an impression that pthreads that are being created by database are not being monitored. I am using the following command: >> psrun -f -c /tmp/perfsuite-1.1.2/perf.xml -o 01 -F text -d all -S 12 -X ./rundb.sh > > If you want to monitor the spawn threads, in addition to the forked processes, you need to give the "-p" (standing for "pthreads") option to psrun as well. That is, in your case, do: > psrun -f -p -c /tmp/perfsuite-1.1.2/perf.xml ... > The "-p" option will cause psrun to generate one XML file per thread, otherwise, only one file is generated, containing the results for just the main thread -- this is likely what happened in your case. > > Thanks, > Rui > > On 04/23/2013 06:12 AM, Hassan, Ahmad wrote: >> Hi Rui, >> >> I found the XML files for database now. It turned out to be very basic mistake. The location of the generated xml file is the relevant location where the database stores its back up files. Thanks for your help. I ran few benchmarks on a 10G dataset and queries touch around 2G of data but the numbers that I am getting from psrun are very small. In addition to that, the number are more or less same for all queries and for different dataset sizes. This gives me an impression that pthreads that are being created by database are not being monitored. I am using the following command: >> >> psrun -f -c /tmp/perfsuite-1.1.2/perf.xml -o 01 -F text -d all -S 12 -X ./rundb.sh >> >> I have attached the results of one query that I executed. The query finishes in millisecs because it is an inmemory database. Any ideas why the numbers are very low and insensitive to dataset size please? >> >> Thanks. >> >> Kind Regards, Ahmad >> SAP >> >> >> -----Original Message----- >> From: Rui Liu [mailto:ru...@il...] >> Sent: 22 April 2013 22:37 >> To: Hassan, Ahmad >> Subject: Re: [PerfSuite-users] psrun for daemon applications >> >> Hi Ahmad, >> >> I temporarily removed the mailing list so we don't cause too many mails for them. :-) >> >>> 1) There is a DB script which runs the database process as a daemon so If I do that then the 'psrun' immediately creates the XML after starting the database process. So this xml file doesn't show the numbers for the running database because the DB is still in the running phase. If I stop the database, the xml file stays the same : >>> psrun -f DB_exec start >>> 2) In the second case, instead of using the wrapper script 'DB_exec' for starting the database process, I started the database binary myself and put '&' in the end: >>> psrun -f run_db params & >>> In the second case, no xml file is generated even after I kill the db process through SIGTERM or SIGINT or SIGKILL. >> >> >>> One of the thing I notice that, If I kill the 'top' process using SIGKILL then no XML is created. The xml is only created for 'top' test case if I use SIGTERM or SIGINT. >>> The database has its own signal handler for different signals, can this be a potential cause of what we are seeing? >>> One of the possible solution would be that, if we can trigger 'psrun' to generate XML file while the application is running. Would that be possible? Or some other good solution that you would suggest. >> >> Thanks a lot for trying different ways and reporting the results! >> >> Yes, my understanding is that SIGKILL is brute force, it won't be calling the exit handler, so no PerfSuite XML file will be written. >> >> psrun seemed to have been designed with this need in mind. :-) There is an option "-S" in psrun, to just allow the solution you suggested -- allowing a user to specify a signal number to trigger the writing of the XML file. Details of this option is available by doing "man psrun". "man 7 signal" will show you the values of the signals. In my text below, I used "16" -- the value for SIGUSR1. >> >> Could you please try: >> 1) write a simple script, such as "/tmp/do.sh", containing something similar to: >> ---------- >> #!/bin/sh >> >> run_db params & >> ---------- >> 2) run it with "psrun -f -S <a_signal_number> /tmp/do.sh", then do "ps uf" to find the PID, then "kill -<a_signal_number> <PID>". >> >> I tried the signal number 16: "psrun -f -S 16 /tmp/do.sh" and "kill -16 <PID>", and a valid XML file was generated. :-) >> >> Thanks, >> Rui >> >> >> On 04/22/2013 04:05 PM, Hassan, Ahmad wrote: >>> Hi Rui, >>> >>> Another strange observation. Even if I don't put the database process in the background, but use CTRL^c to stop the process, even then the XML file is not generated for the database. For example the use case I am running is: >>> >>> psrun -f run_db_binary param1 param2 >>> >>> press CTRL^c >>> >>> No xml file. So it seems that there is some kind of dependency on application here? >>> >>> Best Regards, Ahmad >>> SAP >>> >>> >>> -----Original Message----- >>> From: Rui Liu [mailto:ru...@il...] >>> Sent: 22 April 2013 20:48 >>> To: Hassan, Ahmad >>> Cc: per...@li... >>> Subject: Re: [PerfSuite-users] psrun for daemon applications >>> >>> Hi Ahmad, >>> >>> Thanks a lot for your interest in using PerfSuite! >>> >>> What you saw might be the expected behavior -- you might just have to wait for the database daemon process to stop, either a normal finish or being killed, for the XML file to be generated by psrun. >>> >>> I tried a simple test to mimic the behavior you saw: a file "/tmp/do.sh", which contains just: >>> -------------------- >>> #!/bin/sh >>> >>> top -b -n30 > /tmp/top.txt & >>> -------------------- >>> The "&" character makes the "top" process to run in the background, similar to a daemon process. >>> >>> After I ran "psrun -f /tmp/do.sh", psrun returned immediately, just as you said "psrun returns as soon as the database starts and goes into daemon mode". However, "top" kept running, and "psrun" kept measuring it. In the meanwhile, "top" was running the 30 iterations we asked for and no PerfSuite XML file was generated -- this seemed to be what you observed. . After "top" successfully finished, psrun generated a valid file with the count values. >>> >>> In another test, a valid XML file was also generated when I used "kill" to stop the "top" process. I used "ps uf" to find the PID of the "top" process, then used "kill <pid>". If your db process is a long-running one (say it will take days for it to finish), or it never finishes by itself, you could try to kill it. >>> >>> The reason for the behavior is that "psrun" installs an exit handler function for a process it monitors, and when the process exits (either by itself, or by receiving a signal such as the one "kill" sends to it), the exit handler is called and the exit handler writes out the XML file. >>> >>> Could you please try to let your db daemon process exit normally or kill it (try the default signal "SIGTERM" first), check whether a PerfSuite XML file is generated and let us know the result? Please allow the process to run for some time, otherwise most counts could be zero. >>> >>> Thanks, >>> Rui >>> >>> Rui Liu >>> NCSA >>> current PerfSuite maintainer >>> >>> On 04/22/2013 01:56 PM, Hassan, Ahmad wrote: >>>> Hi Team, >>>> >>>> I have installed perfsuite v1.1.2. I want to profile the whole database and measure PAPI events. As the database runs as a daemon process so I couldn't figure out how to use Perfsuite to profile the running database daemon until the daemon stops. I tried the following: >>>> >>>> psrun -f -c papi_sandybridge.xml db_exec start >>>> >>>> But in the above case, psrun returns the output as soon as database starts and goes into daemon mode. Any suggestions please? >>>> >>>> Thanks. >>>> >>>> Kind Regards, Ahmad >>>> >>>> SAP |
From: Rui L. <ru...@il...> - 2013-04-22 20:05:12
|
Hi Ahmad, Thanks a lot for your interest in using PerfSuite! What you saw might be the expected behavior -- you might just have to wait for the database daemon process to stop, either a normal finish or being killed, for the XML file to be generated by psrun. I tried a simple test to mimic the behavior you saw: a file "/tmp/do.sh", which contains just: -------------------- #!/bin/sh top -b -n30 > /tmp/top.txt & -------------------- The "&" character makes the "top" process to run in the background, similar to a daemon process. After I ran "psrun -f /tmp/do.sh", psrun returned immediately, just as you said "psrun returns as soon as the database starts and goes into daemon mode". However, "top" kept running, and "psrun" kept measuring it. In the meanwhile, "top" was running the 30 iterations we asked for and no PerfSuite XML file was generated -- this seemed to be what you observed. . After "top" successfully finished, psrun generated a valid file with the count values. In another test, a valid XML file was also generated when I used "kill" to stop the "top" process. I used "ps uf" to find the PID of the "top" process, then used "kill <pid>". If your db process is a long-running one (say it will take days for it to finish), or it never finishes by itself, you could try to kill it. The reason for the behavior is that "psrun" installs an exit handler function for a process it monitors, and when the process exits (either by itself, or by receiving a signal such as the one "kill" sends to it), the exit handler is called and the exit handler writes out the XML file. Could you please try to let your db daemon process exit normally or kill it (try the default signal "SIGTERM" first), check whether a PerfSuite XML file is generated and let us know the result? Please allow the process to run for some time, otherwise most counts could be zero. Thanks, Rui Rui Liu NCSA current PerfSuite maintainer On 04/22/2013 01:56 PM, Hassan, Ahmad wrote: > Hi Team, > > I have installed perfsuite v1.1.2. I want to profile the whole database and measure PAPI events. As the database runs as a daemon process so I couldn’t figure out how to use Perfsuite to profile the running database daemon until the daemon stops. I tried the following: > > psrun -f -c papi_sandybridge.xml db_exec start > > But in the above case, psrun returns the output as soon as database starts and goes into daemon mode. Any suggestions please? > > Thanks. > > Kind Regards, Ahmad > > SAP > > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > > > > _______________________________________________ > PerfSuite-users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perfsuite-users > |
From: Hassan, A. <ahm...@sa...> - 2013-04-22 18:57:08
|
Hi Team, I have installed perfsuite v1.1.2. I want to profile the whole database and measure PAPI events. As the database runs as a daemon process so I couldn't figure out how to use Perfsuite to profile the running database daemon until the daemon stops. I tried the following: psrun -f -c papi_sandybridge.xml db_exec start But in the above case, psrun returns the output as soon as database starts and goes into daemon mode. Any suggestions please? Thanks. Kind Regards, Ahmad SAP |
From: Rui L. <ru...@il...> - 2013-01-22 17:02:05
|
PerfSuite 1.1.2 is now available. The major highlights of this release are: - PAPI 5.x is now supported, a bit overdue. - Some users reported that with GNU OpenMP implementation, PerfSuite only generated one XML file, instead of one file for each OpenMP thread. Made an attempt to solve this issue. - Occasionally the PAPI multiplexed thread test in the libpshwpc test suite fails. Split it into two tests: one for 1-4 threads, and the other for 8-256 threads, and made the result of the second one "expected-failure", so it will be considered passed while the log file will be kept for debugging. This release also contains other enhancements and bug fixes. A complete listing of changes can be found in the CHANGES file. URL: http://sourceforge.net/projects/perfsuite Thanks and enjoy, Rui |
From: Rui L. <ru...@il...> - 2012-05-22 22:13:17
|
PerfSuite 1.1.1 is now available. The major highlights of this release are: - New support for AMD Interlagos and Intel Sandy Bridge processors. - At the end of "configure" output, print out a new section named "Configuration Summary", to indicate the OK/warning status. - Removed the display of "family" and "model" in processor information (the "cpuinfo" tag), and use the CPUID output where it's appropriate. This affects the text and XML output of psinv, psrun and libpshwpc, and the DTDs. - psinv: added a "-b" option to display the build details, including the entire "configure" command line, hostname and current working directory. - Last release (1.1.0) added the detection of Intel Westmere processors, but missed the inclusion of their default event configuration file. Added the file "papi3_wsm.xml". This release also contains other enhancements and bug fixes. A complete listing of changes can be found in the CHANGES file. URL: http://sourceforge.net/projects/perfsuite Thanks and enjoy, Rui |
From: Rui L. <ru...@nc...> - 2011-10-19 14:12:28
|
Forwarding to the perfsuite-users mailing list, as these questions or requests might be common... -------- Original Message -------- Subject: Re: Comment for PerfSuite feature request Date: Tue, 18 Oct 2011 15:23:41 -0700 From: Pavlush Margarian <pa...@gm...> To: Rui Liu CC: Rick Kufrin Dear Rui, Thanks a lot for quick reply! For Item #1: It's now clear for me that currently there is no way to control use of this signal. We use PAPI 4 with perfctr, so SIGPROF signal is used, we can't use this signal elsewhere in our application. For item #2: We use native binary executable, I already tried to run and profile multiple times. It's not so accurate as environment is different run to runs, also, run can last more that 24 hours, so run-time is serious constraint for this workaround. We can talk about this later. Probably we can help you to implement this feature if it's possible. Please let me know if there is such option. ... Thanks, Pavlush. On Tue, Oct 18, 2011 at 2:22 PM, Rui Liu wrote: Dear Pavlush, Thanks a lot for the prompt clarification! For item #1, "Allow a user to specify a signal to use when profiling", unfortunately this is not possible. (1) When the 3 itimer types: ITIMER_PROF, ITIMER_REAL and ITIMER_VIRTUAL, are used to profile, it is mandated by the Linux system calls that signals of the types SIGPROF, SIGALRM and SIGVTALRM be generated, respectively. Please see setitimer man page for more details. (2) When a PAPI event is used to profile, then PAPI's overflow mechanism is used. Browsing through PAPI's source code and testing confirmed that the signal types PAPI used (in recent 4.0.0+ versions) are: Substrate The signal type used -------------------------------------------- perf_events SIGRTMIN+2 (found to be 36) perfmon same as above perfctr SIGPROF (27) Since in this case PerfSuite uses PAPI to profile and to my knowledge, currently there exists no such PAPI option that can be set through PAPI_set_opt(), it seems impossible to change the signal type being used. Hopefully with the above info in mind, there is a possible workaround in your situation. For item #2, "Allow a user to profile using multiple events", yes this is a limitation known to us for native binary executables. (1) For Java applications, the PerfSuite 1.1.0 version released today contained a JVMTI-based agent named "psjprof", which can profile using multiple PAPI events simultaneously. (2) For a native binary executable, we might consider supporting it in the future, but currently there is no fixed plan. A possible workaround might be run and profile the program multiple times, each time using a different event. ... Thanks, Rui On 10/18/2011 12:39 PM, Pavlush Margarian wrote: > Dear Rui, > > Thank you for reply. I looked your comment on the source forge web site. > Let me clarify my question: in Profiling Mode, when you profile some particular event, is there any way to specify signal, which I want to use for interrupts? > As far as I understand PerfSuite (PAPI) generates an interrupt, when number of events, for particular function, reaches specified "threshold" value (in config .xml). > In profiling mode source of signal it's not an interval timer. Could you please confirm If I understand behavior correctly. > > For example, I have xml config file, which I use to profile L2 cache misses, looks like PerfSuite uses SIGPROF signal in this case. Is there a way to specify some other signal instead? > Here is my xml file how should I specify signal here? > > <?xml version="1.0" encoding="UTF-8" ?> > <ps_hwpc_profile class="PAPI"> > <!-- ========================================================== > This is a configuration file that can be used to ask for > profiling, based on total level 2 cache misses with a > period of 100,000. > > $Id: papi_profile_l2tcm.xml,v 1.1 2004/01/12 02:15:44 rkufrin Exp $ > ========================================================== --> > <ps_hwpc_event type="preset" name="PAPI_L2_TCM" threshold="100000"/> > </ps_hwpc_profile> > > Also, one more feature that is very important for me. > Looks like PerfSuite doesn't support multiple events simultaneously in Profiling Mode. Do you have any plans to add this feature? > > > Regards, > Pavlush. > > On Tue, Oct 18, 2011 at 8:26 AM, Rui Liu <rli...@us...> wrote: > > Dear Pavlush, > > I added a comment for your June 30 feature request for the > PerfSuite project on the source forge web site. > > Thanks, > Rui |
From: Rui L. <ru...@nc...> - 2011-10-18 14:33:30
|
PerfSuite 1.1.0 is now available. The major highlight of this release is a new JVMTI-based agent named "psjprof", that can be used to profile Java programs using hardware performance counters. The agent allows profiling of unmodified Java applications in a manner similar to the "psjrun" agent. The manual page and design document for it are included. This release also contains several miscellaneous fixes and cleanups. A complete listing of changes can be found in the CHANGES file. URL: http://sourceforge.net/projects/perfsuite Rui |
From: Rick K. <rk...@nc...> - 2011-08-16 02:15:20
|
Hello all, I'm writing to let you know that I am leaving NCSA/University of Illinois and will be handing off the leadership of PerfSuite from myself to my colleague Rui Liu, who has been working with me for the past three years on PerfSuite development, maintainance, and support. The project is very much alive and will be in excellent hands: I have been remiss in introducing Rui to you all previously so I will correct that. Rui joined NCSA and PerfSuite in 2008 and has been very involved in development of existing software and is the sole developer of all recent Java-based software in PerfSuite. He wasn't a rookie when he came to NCSA: after graduating from the Computer Science graduate program at the University of Illinois, he was a key member of the development team at a startup that was subsequently acquired by Cisco Systems. He continued to work at Cisco for some time, and decided he wanted to return to the more laid-back lifestyle here in the midwest. He's now settled in and has made significant contributions not only to PerfSuite, but to the broader mission of HPC at NCSA. A better debugger may not exist :) And as for me - I would like to thank you all for your interest in PerfSuite and for participating in this list and using the software; I hope it has been some help to you in your work! Best wishes, Rick |
From: Rick K. <rk...@nc...> - 2011-05-13 00:24:20
|
Greetings all, Normally I would not forward messages from another mailing list to this one, but I think the below posting from the PAPI mailing list is important enough to go ahead and forward as it concerns an issue that affected us (and the PAPI team helped sort it out) and may also affect anyone who uses similar Linux distributions as we do. The PerfSuite test suite triggers "Bug 2", described below, and can render the system useless - unresponsive, and in need of a hard reboot. We ran into this with the recent release of Ubuntu 11.04, and found that upgrading to a mainline kernel >= 2.6.38-4 was required to set things right again. Rick ----- Forwarded Message ----- From: "Vince Weaver" <vwe...@ee...> To: pto...@cs..., per...@cs... Sent: Thursday, May 12, 2011 4:32:52 PM Subject: [Ptools-perfapi] potential kernel crashes with perf_event substrate Hello Recent Linux kernels have bugs with the perf_event subsystem which can be triggered by PAPI. These bugs can lead to kernel panics and system crashes. The bugs have been fixed upstream but the fixes are only gradually getting into vendor kernels. If your code causes a crash, you should upgrade to a kernel with the fixes applied. Bug 1 involves "inherit" support. perf_event inherit support was only added to PAPI as of the recent 4.1.3 release. This bug causes a memory leak in the kernel that will eventually out-of-memory your machine with unfreeable memory. It is triggered by using the perf_event substrate to measure at least two events with the "inherit" option set, then running a multithreaded workload. The fix for this will be in the forthcoming 2.6.39 Linux kernel, and the patch has been included in the relevant stable series trees (2.6.38.2, etc.). The changeset for the fix is: 38b435b16c36b0d863efcf3f07b34a6fac9873fd Bug 2 involves multiplexing support (PAPI will only use kernel multiplexing on kernels 2.6.33 and newer). If you use multiplexing on multithreaded workloads you can eventually see a kernel panic. The fix for this will be in the forthcoming 2.6.39 Linux kernel, and the patch has been included in the relevant stable trees (2.6.38.4, etc.). The changeset for the fix is: ab711fe08297de1485fff0a366e6db8828cafd6a Vince vwe...@ee... _______________________________________________ Ptools-perfapi mailing list Pto...@ee... http://lists.eecs.utk.edu/mailman/listinfo/ptools-perfapi |
From: Rick K. <rk...@nc...> - 2011-03-15 21:18:34
|
PerfSuite 1.0.0 final is now available. There are no changes from version 1.0.0 beta 2, only the modification of the release number to show it is a final release and is considered stable (vs. development). URL: http://www.sf.net/projects/perfsuite Rick |
From: Rick K. <rk...@il...> - 2011-02-15 20:23:12
|
PerfSuite 1.0.0 beta 2 is now available. The primary change to this release is extended x86 processor recognition that allows PerfSuite to be used on Intel Westmere processors. This release also contains several miscellaneous fixes and cleanups. A complete listing of changes can be found in the CHANGES file. URL: http://www.sf.net/projects/perfsuite Rick |
From: Rui L. <ru...@nc...> - 2011-02-08 16:40:17
|
Hi wkq, Wall clock time = <wallclock ticks in the psrun-generated XML>/<CPU freq> psrun uses libpshwpc's API functions ps_hwpc_start() and ps_hwpc_stop() to start and stop the counting or profiling, which in turn use libperfsuite's API function ps_rtc() to record the start and end ticks. ps_hwpc_stop also writes the output file; the "wallclock" element in the output file contains the difference of the start and end ticks. The ps_rtc() function samples a high resolution wallclock (real time) timer, which differs on each architecture/system. Thanks, Rui On 02/08/2011 01:46 AM, 吴名 wrote: > Hi Rui, > I check the metric in the link > http://perfsuite.ncsa.uiuc.edu/psprocess/metrics.shtml, > the Wall clock time (seconds) is not there, I don't know the exact > meaning. since I run the command, CPU time equals > cycles/cpu freq, and the total elpased time is not Wall clock > time.(you can use gettimeofday to verify it). So wall clock time > meaning ? How does psrun get the value?? > > > Thanks. > > wkq > |
From: Rui L. <ru...@nc...> - 2011-01-28 19:23:52
|
Hi wkq, Thanks for updating us on your progress, and glad to know that it works for you! Regarding getting counter values periodically, "psrun" does not support this feature. There might be other tools that support this, but I'm not aware of a currently maintained one. Using a combination of available features -- PerfSuite's libpshwpc API, interval timer and signal handler -- it could be possible to achieve that, but it involves changes to a user's source code, and might not work for a threaded program. An example is in the PerfSuite installation directory, under "share/perfsuite/examples/sampler/". Please be aware that this is unsupported and you are on your own to go this direction. Thanks, Rui On 01/28/2011 05:25 AM, 吴名 wrote: > Oh, thanks. solved. > Does perfsuite support sampling with specified interval ? Since I want > to get performance counter data every n seconds. > Until now, I can't find the option for psrun to do this job. > > Thanks. > > wkq > > > 2011/1/28 Rui Liu <ru...@nc...>: >> Hi wkq, >> >> Thanks for updating us on your progress and glad to know that "psrun" works >> for you now with the customized configuration file! >> >>> But when I run psprocess *.xml, >>> it prints: >>> exec: 83: -classpath: not found >> This usually happens when a user did not use the "--enable-java" option when >> running "configure". By default, "psprocess" now uses a Java >> implementation, so this message will show up in such situation. There are 2 >> solutions: >> >> 1) The recommended solution. If you have Java of version 1.5 or higher >> installed, then run "configure ...", "make" and "make install" again, and >> add "--enable-java" when you run "configure". Then "psprocess" should work. >> 2) If Tcl is installed on your machine, then you can use the Tcl >> implementation of psprocess, by doing "psprocess --tcl ...". We plan to >> keep on supporting the Java implementation and not the Tcl one, so this is >> not the recommended solution. >> >> >>> ... but you can see 8406186437 - 8400025761 = 6160676, (still a >>> big number), Which one is more strict?? or they are same, the error is >>> allowable ? >> Although the magnitude of the difference might seem large, the percentage is >> small: 6160676 / 8406186437 ~= 0.07%, so it could be ignorable. There are >> many factors that could affect the final values of the hardware performance >> counters. An email to the PAPI mailing list that John McCalpin posted on >> 2009-10-22 was a good and detailed overview of some tips and pitfalls for >> using hardware performance counters. It's at: >> >> http://lists.eecs.utk.edu/pipermail/ptools-perfapi/2009-October/001386.html >> >> Thanks, >> Rui >> >> >> On 01/27/2011 06:43 AM, 吴名 wrote: >>> Of course, I can use text output format, but why xml is not ok. >>> >>> Besides, if I use PERF_COUNT_HW_INSTRUCTIONS, "sys_perf_event_open: >>> sys call function, >>> >>> for this part >>> void cpu() >>> { >>> unsigned int i = 1; >>> int a = 1, b = 2; >>> while(i++ < 1200000000) >>> { >>> a = a + b; >>> } >>> } >>> >>> my prints 8406186437, and every time is different. may 8396328126, ... >>> While psrun with PAPI_TOT_INS, 8400025761, (every time is dfferent >>> too), but you can see 8406186437 - 8400025761 = 6160676, (still a >>> big number), Which one is more strict?? or they are same, the error is >>> allowable ? >>> >>> Thanks a lot. >>> >>> wkq >>> >>> >> -------- Original Message -------- >> Subject: Re: Hardware event not available ?? >> Date: Thu, 27 Jan 2011 17:52:08 +0800 >> From: 吴名 <wk...@gm...> >> To: Rui Liu <ru...@nc...> >> References: <AAN...@ma...> >> <4D4...@nc...> >> >> Thank you for you quick reply. Yes, psrun can work now. I can only viem >> But when I run psprocess *.xml, >> >> it prints: >> exec: 83: -classpath: not found >> >> seems I don't have proper environment path. expat problem ? But >> configuration shows no problem. >> configure: configuring Expat support >> checking expat.h usability... yes >> checking expat.h presence... yes >> checking for expat.h... yes >> checking for XML_ParserCreate in -lexpat... yes >> >> >> wkq >> >>> 2011/1/27 Rui Liu <ru...@nc...>: >>>> Hi wkq, >>>> >>>> Thanks for contacting me! And sorry for your previous mails not getting >>>> through. >>>> >>>> Yes, PerfSuite should work on Intel Xeon. What you are seeing is because >>>> some events in the default PerfSuite pshwc configuration file are not >>>> available on that CPU. One solution is to define a configuration file to >>>> use with "psrun": >>>> >>>> 1) create a file, for example, "events.xml", with the following content: >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?> >>>> <ps_hwpc_eventlist class="PAPI"> >>>> <ps_hwpc_event type="preset" name="PAPI_TOT_CYC" /> >>>> </ps_hwpc_eventlist> >>>> >>>> 2) Start "psrun" using this configuration file: >>>> psrun -c <absolute_or_relative_path_to_"events.xml"> <your_program> >>>> then it should work and generate an XML file, and you can use "psprocess >>>> <generated_xml_file_name>" to view the processed output. >>>> >>>> After this works, you can customize the file "events.xml" to count the >>>> events that interest you. For example, if you want to count the total >>>> number of instructions and L2 total cache miss, and "papi_avail" output >>>> shows that PAPI_TOT_INS and PAPI_L2_TCM are available on your CPU, then >>>> you >>>> can change "events.xml" to contain: >>>> >>>> <?xml version="1.0" encoding="UTF-8" ?> >>>> <ps_hwpc_eventlist class="PAPI"> >>>> <ps_hwpc_event type="preset" name="PAPI_TOT_INS" /> >>>> <ps_hwpc_event type="preset" name="PAPI_L2_TCM" /> >>>> </ps_hwpc_eventlist> >>>> >>>> and use it with "psrun" by doing "psrun -c <path_to_"events.xml"> >>>> <your_program>". >>>> >>>> On the other hand, if you put in an event that is not available on your >>>> CPU >>>> in this file, and use it with "psrun", then psrun will stop with the >>>> error >>>> message "hardware event not available". That is what's happening in your >>>> case -- some events in the default configuration file are not available >>>> on >>>> your CPU. The default config file "psrun" uses can be found at the >>>> bottom >>>> of "psrun -h" output. >>>> >>>> Please let us know how it goes or if you have more questions. Good luck! >>>> >>>> Thanks, >>>> Rui >>>> >>>> On 01/26/2011 08:43 AM, 吴名 wrote: >>>>> Hi Mr Liu, >>>>> I tried to send you from 163.com, your reply in PAPI mail list, but >>>>> the ncsa always deny my mail, :( >>>>> So I try this gmail. >>>>> >>>>> I installed perfsuite, but the psrun won't work. (install is right) >>>>> (Hardware event not available) But PAPI can work. >>>>> I run examples hl, still the same problem, Does this suite support >>>>> intel xeon processor ? >>>>> >>>>> >>>>> I really looking forward to your reply. >>>>> The mail list about perfsuite still need some time to approve my >>>>> subscribe. So I send to you first. >>>>> Thanks. >>>>> >>>>> wkq >>>>> > |
From: wkq5325 <wk...@16...> - 2011-01-27 01:37:41
|
Does perfsuite support xeon processor?? I install the suite, but when I run psrun, but papi program can work fine. it prints: Hardware event not available. I run example "hl" still same error. Thanks wkq |
From: Rick K. <rk...@il...> - 2010-10-27 19:24:34
|
PerfSuite 1.0.0 beta 1 is now available. The major highlight of this release is new support for POWER/Linux systems. PerfSuite now supports POWER4 and later platforms. This release also contains several miscellaneous fixes and cleanups. A complete listing of changes can be found in the CHANGES file. URL: http://www.sf.net/projects/perfsuite Rick |
From: Rick K. <rk...@il...> - 2010-09-14 19:52:57
|
PerfSuite 1.0.0 alpha 5 is now available. Highlights of this release include: * Several bug fixes and improvements provided courtesy of Daniel Thomas of SGI. We are very grateful to Daniel for his valuable contributions and to SGI for their continuing support of open source software. * The psprocess command has been changed to use the Java version, released in PerfSuite 1.0.0a3, as the default mode for operation. The Tcl version of psprocess available in prior releases is still available, but has been deprecated. * Additional bug fixes and enhancements. A complete listing of changes can be found in the CHANGES file. URL: http://www.sf.net/projects/perfsuite Rick |
From: Rick K. <rk...@il...> - 2010-08-26 00:28:14
|
PerfSuite will be participating in a full-day tutorial to be presented at this year's Supercomputing conference in New Orleans, Louisiana. The title of the tutorial is "Hands-On Practical Performance Engineering Using PAPI, PerfSuite, Scalasca, Vampir, and TAU". Attendees will receive a bootable LiveDVD or LiveUSB that contains pre-installed versions of all the software covered in the tutorial and much more software of interest to HPC users. This LiveDVD will be used to drive hands-on sessions during the tutorial and can be used afterwards at your home institutions. The tutorial will take place on Monday, November 15th, 2010. Further details can be found at: http://sc10.supercomputing.org/schedule/event_detail.php?evid=tut120 Registration is now open for SC10: http://sc10.supercomputing.org Rick |
From: Rick K. <rk...@il...> - 2010-08-17 01:18:22
|
Subscribers to this list may be interested in a presentation made to the TeraGrid AUS (Advanced User Support) group in May that discusses work to apply PerfSuite and other tools from the POINT SDCI project to locating and addressing bottlenecks in a real-world CFD application developed at Virginia Tech and deployed on the NCSA Altix ("Cobalt"). The audio/slides can be viewed here: http://tinyurl.com/KufrinASTA Rick |