2013-08-02
* 6b62d586 man/man1/papi_avail.1 man/man1/papi_clockres.1
man/man1/papi_command_line.1...: Update the manpages for a pending 5.2
release. New pages for PAPI[F]_epc and papi_version.
* 1ae08835 src/linux-common.c: try to properly detect number of sockets Use
totalcpus rather than ncpu in the calculation. This change fixes things on a
Sandybridge-EP machine. We should maybe find a more robust way to detect
this.
* 79c37fbf .../perf_event_uncore/tests/perf_event_uncore.c
.../tests/perf_event_uncore_multiple.c: perf_event_uncore: have tests skip if
component disabled rather than fail
* 638ccf6b .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
change order of uncore detection logic This way it will report an error of
"no uncore found" before it reports "not enough permissions". That way a
user won't waste time getting permissions only to find out they didn't have
an uncore anyway.
* 30582773 src/components/perf_event/pe_libpfm4_events.c: perf_event: fix
papi_native_avail output A recent change of mine that added stricter error
checking for libpfm4 event lookup broke event enumeration on perf_event,
specifically papi_native_avail output. libpfm4 will return an error on some
events if no UMASK or improper UMASK is supplied, but papi_native_avail
always wants to print the root event and umasks separately. this temporary
fix just ignores libpfm4 umask errors; we might in the future want to
properly indicate which events are only valid when certain umasks are
present.
* c7612326 src/utils/native_avail.c: papi_native_avail: fix empty component
case If a component had no events, papi_native_avail would ignore the error
returned by PAPI_enum_cmp_event( PAPI_ENUM_FIRST ); and try to print a first
event anyway.
* e1b064eb .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
disable component if no events found This can happen on older (pre 3.6)
kernels with the new libpfm4 that does proper uncore detection.
2013-08-01
* 9a54633a src/components/host_micpower/linux-host_micpower.c
src/components/infiniband/linux-infiniband.c
src/components/nvml/linux-nvml.c...: Components: Use the cuda dlopen fix all
cases. See 4cb76a9b for details, the short version is if you call dlopen
when you have been statically linked to libc, it gets ugly.
2013-07-31
* dbc44ed1 src/components/perf_event/pe_libpfm4_events.c
.../perf_event_uncore/perf_event_uncore.c
.../perf_event_uncore/peu_libpfm4_events.c: perf_event libpfm4 events --
correctly handle invalid events It was possible for event names to be
obtained from libpfm4 during enumeration that were not valid events. This
usually happens with uncore events, where the uncore is listed as available
based on cpuid but when libpfm4 tries to get the uncore type from the kernel
finds out it is unsupported. This change makes this properly fail, instead
of just returning "0" for all the event paramaters (which is a valid event on
x86). Also make this change in the regular perf_event component, even though
it is less likely to happen in practice.
* 4720890a .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
remove check_permissions() test It was trying to see if an EventSet was
runnable by using the current permissions and adding the PERF_HW_INSTRUCTIONS
event. That doesn't really make sense on uncore. The perf_event component
uses this test to try to give errors early, at set_opt() time rather than at
the first run time, although in practice now we can probably make intelligent
guesses based on the current permission levels.
* 113d35f7 .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
remove unused kernel workarounds uncore only works on Linux 3.6 or newer so
all of the pre-2.6.35 workarounds aren't necessary. If someone has
backported the uncore support to kernels that old, hopefully they've also
backported all the other bugfixes too.
2013-07-25
* 4cb76a9b src/components/cuda/linux-cuda.c: Trial fix for the cuda component
static libc linking issue. Weak link against _dl_non_dynamic_init, this
appears in my limited testing to be in gnu libc.a and not in the so. For
background, it was reported by Steve Kaufmann that statically linking tools
with a PAPI library configured with the CUDA component segfaulted. It appears
that calling any of the dynamic linker functions from a static executable is
asking for pain. See Trac bug 182
https://icl.cs.utk.edu/trac/papi/ticket/182
2013-07-24
* ad47cfb9 src/configure src/configure.in: Add linux-pfm-ia64 to configure
I'm not sure if this is enough to fix itanium support but it's a start.
* 098294c5 src/components/example/tests/example_basic.c
.../example/tests/example_multiple_components.c: Fixed tests for example
component. Both tests failed due to incorrect check of the components PAPI
has been configured with.
2013-07-23
* c0c4caf4 src/linux-memory.c src/papi_events.csv: Add initial support for
IBM POWER8 processor Add initial support for IBM POWER8 processor The IBM
POWER8 processor (to be publicly announced at some future date) has some
preliminary support in libpfm with a subset of native events. These
POWER8-related libpfm changes were pulled into PAPI on July 3, so further
updates in PAPI were required to support this new processor. This patch adds
that required support. NOTE: Due to the fact that only a subset of native
events have been publicised at this point (and pushed into libpfm), not all
of the usual PAPI preset events have corresponding native events. The rest of
the POWER8 native events will be pushed upstream once they are verified, and
then we can flesh out the PAPI preset events. With this initial POWER8
support patch, 5 of the ctests and ftests fail, compared to 3 when PAPI is
run on a POWER7. At least one of the failing testcases is due to testing
being done on an early POWER8 processor with some known hardware problems. We
presume the number of failing tests will decrease once we have GA-level
hardware to test on.
2013-07-22
* 6c231d1a src/configure: Rerun autoconf for f4ec143e Correct versioning of
libpapi.so
* f4ec143e src/configure.in: Correct versioning of libpapi.so The configure
for linux always set the soname to libpapi.so. This causes problems when
/sbin/ldconfig tries to update the library information on linux. The shared
library is installed as /lib{64}/libpapi.so.$VERSION, but the shared library
has the soname of libpapi.so. ldconfig makes a symbolic link from
/lib/libpapi.so to the actual versioned shared library,
/lib/{64}/libpapi.so$VERSION. The configure should get the soname correct to
avoid creating this symbolic link. This patch only addresses the issues for
some of the possible platforms and similar patches may be needed for other
platforms.
2013-07-19
* 92356bbd src/papi.c src/threads.c src/threads.h: Attempt to fix a memory
leak in fork2 test. Fork2 does the following: PAPI_library_init() fork(); /
\ parent child wait() PAPI_shutdown() ->
_papi_hwi_shutdown_global_threads() -> foreach(threadinfo we allocated):
_papi_hwi_shutdown_thread() PAPI_library_init() _papi_hwi_shutdown_thread
checks who allocated a ThreadInfo entry in the global list, and will only
free it if our thread did the allocation. When threading is not initialized,
we fall back to getpid(), now in the child process, the one ThreadInfo item
on the list was allocated by our parent, so at shutdown time we don't free
this, and thus leak it. Solution is to add a parameter to
_hwi_shutdown_thread to force shutdown even if we didn't allocate it. At
_papi_hwi_shutdown_global_threads() time, who cares, its closing time.
* c04d908e src/cpus.c: Fix a deadlock in _papi_hwi_lookup_cpu(). If cpu_num
is not found by _papi_hwi_lookup_cpu(), _papi_hwi_initialize_cpu() calls
insert_cpu(), which locks CPUS_LOCK, which was already held by
_papi_hwi_lookup_cpu().
* efac24c4 src/components/micpower/linux-micpower.c: micpower: fix return
value check Also add a time check at stop time.
2013-07-16
* b9fd9dd1 src/configure src/configure.in: configure: Fix AIX build
perfctr_ppc was not the only system that relied on ppc64_events.h, power*.h,
and friends. First run at a fix is -Icomponents/perfctr_ppc for the C and F
flags...
* 46042e68 src/components/micpower/linux-micpower.c: micpower: update some
indexing code
2013-07-15
* 5220e7d2 INSTALL.txt: INSTALL.txt: typo --with-arch=, not --arch=; Thanks
to Karl Schulz for catching this.
* 207e0ee0 src/papi_libpfm_events.h: papi_libpfm_events: needs include files
for types. Include papi.h and papi_vector.h for papi_vector_t and
PAPI_component_info_t
* d96c01c7 src/components/perfctr/perfctr.c: perfctr: cleanup a warning
Include papi_libpfm_events.h for _papi_libpfm_init() decl.
* 367e1b38 src/components/perfctr/perfctr-x86.c
src/components/perfctr/perfctr.c: perfctr: refactor out setup_x86_presets
The setup_presets function served only to call _papi_libpfm_init, so we go
the rest of the way and completly remove the function, calling
_papi_libpfm_init directly from _perfctr_init_component.
* 1ba38ce5 src/components/perfctr/perfctr-x86.c: perfctr: cleanup unused
parameter warning. The perfctr code was refactored to only call into the
table loading code one time. This had the side effect of removing most of
what setup_x86_presets does.
* 02710ced src/configure src/configure.in: configure: remove debugging
message The compiler detection code had a stray AC_MSG_RESULT.
2013-07-12
* 028ce29d src/components/lustre/linux-lustre.c: lustre: use whole directory
name as event Gary Mohr reported that on a trial system he was seeing many
events of the form fs3-* which were all chopped to fs3, not helpful. I've
not actually been able to figure out exactly how lustre names things, I've
seen it described as <fs>-<uid> But have no clue what uid promisses.
2013-07-15
* 129d4587 src/papi.c: allow more than one EventSet attach to a CPU at a time
This is necessary for perf_event_uncore support, as multiple uncores will
want to attach to a CPU. It looks like this change won't break anything, and
the tests pass on my test machines. I am a bit concerned about
cpu->running_eventset, though no one seems to use that value...
* bcda5ddd src/components/perf_event_uncore/tests/Makefile
.../tests/perf_event_uncore_nogran.c: perf_event_uncore: remove
perf_event_uncore_nogran test It is unnecessary after recent changes to the
uncore component.
* b1b9f654 src/components/perf_event_uncore/tests/Makefile
.../tests/perf_event_uncore_cbox.c: perf_event_uncore: add
perf_event_uncore_cbox test This adds a non-trivial test of the CBOX
uncores. It turned up various bugs in the PAPI uncore implementation.
* df1b6453 src/linux-common.c: linux: properly set hwinfo->socket value It
was being derived from hwinfo->ncpu but being calculated before hwinfo->ncpu
was set.
2013-07-13
* ee537448 .../perf_event_uncore/perf_event_uncore.c
.../perf_event_uncore/peu_libpfm4_events.c
.../perf_event_uncore/peu_libpfm4_events.h: perf_event_uncore: properly
report number of total counters available
* 7eb93917 src/components/perf_event/Rules.perf_event
src/components/perf_event/pe_libpfm4_events.c
src/components/perf_event/pe_libpfm4_events.h...:
perf_event/perf_event_uncore/libpfm4 -- rearrange files Give perf_event and
perf_event_uncore copies of papi_libpfm4_events to work with, as they will
have different needs for the code. Get rid of the perf_event_lib stuff. It
was a hack to begin with and in the end not much code will be shared. Maybe
we can re-share things once uncore support is complete.
2013-07-12
* 6810af2a src/components/perf_event/perf_event.c
.../perf_event_uncore/perf_event_uncore.c src/papi_libpfm4_events.c...:
papi_libpfm4: properly call pfm_terminate() in papi_libpfm4_shutdown
* 010497f4 src/components/perf_event/perf_event.c
.../perf_event_uncore/perf_event_uncore.c src/papi_libpfm4_events.c...: split
papi_libpfm4_init() split this function because the perf_event_uncore()
component is going to want to initialize things differently than plain
perf_event
* d9023411 src/components/perf_event/perf_event.c: perf_event: on old kernels
if SW Multiplex enabled, then report proper number of MPX counters available
it may be different than the amount HW supports
* 7595a840 src/components/perf_event/perf_event_lib.c: perf_event: use
PERF_IOC_FLAG_GROUP when resetting events This ioctl argument specifies to
reset all events in a group, so we don't have to iterate. This argument
dates back to the introduction of perf_event and it makes the code a bit
cleaner.
* f220fd19 src/ctests/Makefile src/ctests/reset_multiplex.c: Add
reset_multiplex.c PAPI_reset() potentially exercises different paths when
resetting normal and multiplexed eventsets, so make sure we test both.
* f784a489 src/components/lustre/linux-lustre.c: lustre: botched a conflict
resolution properly do error checking on addCounter()
* c1350fc8 src/components/perf_event/perf_event.c
src/components/perf_event/perf_event_lib.c
src/components/perf_event/perf_event_lib.h: perf_event: move overflow and
profile code out of common lib the perf_event_uncore component doesn't need
it
* 8dde03fc .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
remove profiling and overflow code perf_event doesn't support sampling or
overflow on uncore
* 30d23636 src/components/lustre/linux-lustre.c: lustre component: Several
fixes 1. create a dynamic native events table in pathalogical cases, lustre
can have lots of events. 2. resolve some warnings change signature of
init_component properly error check addCounter 3. Add a preprocessor flag to
fake interface Set LIBCFLAGS="-DFAKE_LUSTRE"
* 7ef51566 .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
remove dispatch timer call perf_event doesn't support sampling on uncore
events
* 667661c6 src/components/perf_event/perf_event.c
src/components/perf_event/perf_event_lib.c
src/components/perf_event/perf_event_lib.h: perf_event: move rdpmc detection
back into perf_event.c It was in the perf_event_lib but uncore won't use the
feature.
* d46f01e1 .../perf_event_uncore/perf_event_uncore.c: perf_event_uncore:
check the paranoid file Disable the component if paranoid isn't 0 or lower,
and we're not running as root.
* e4ec67d1 src/components/perf_event/perf_event.c: perf_event and paranoid
level 2 If paranoid level 2 (no kernel events) was set we were removing
PAPI_DOM_KERNEL from the allowable domains We were doing this even if the
user was root. This code checks for uid 0 and overrides the restriction.
* c5501081 src/components/perf_event/perf_event_lib.c
src/components/perf_event/perf_event_lib.h: rename sys_perf_event_open2()
call back to sys_perf_event_open() This was changed when merging code to
avoid a conflict but wasn't renamed back whe the conflict was fixed.
2013-07-11
* e263ea60 src/configure src/configure.in: configure: libpfm selection logic
rework If configure detected perfctr it would force libpfm3 to be used, even
with --with-perf_events, now force libpfm4 if perf_events is requested.
2013-07-10
* 7a3ce030 .../host_micpower/Makefile.host_micpower.in
src/components/host_micpower/Rules.host_micpower
src/components/host_micpower/configure...: Component: host_micpower This is
a component that exports power information for Intel Xeon Phi cards (MIC).
The component makes use of the MicAccessAPI distributed with the Intel
Manycore Platform Software Stack.
k-mpss)
* 9d9bd9c2 src/ctests/shlib.c: Fwd: Re: [Ptools-perfapi] ctests/shlib FAILED
Should have sent this to the papi devel list. -Will -------- Original
Message -------- Subject: Re: [Ptools-perfapi] ctests/shlib FAILED Date: Tue,
09 Jul 2013 23:20:10 -0400 From: William Cohen <wcohen@redhat.com> To:
ptools-perfapi@eecs.utk.edu On 03/09/2012 03:40 PM, William Cohen wrote: > I
was looking through the test results and found that ctests/shlib FAILED on
all the machines I tested on because libm shared library is already linked
in. There is no difference in the number of shared libraries before and after
the dlopen. The test ctests/shlib fails as a reult of this. > > -Will >
_______________________________________________ > Ptools-perfapi mailing list
> Ptools-perfapi@eecs.utk.edu >
http://lists.eecs.utk.edu/mailman/listinfo/ptools-perfapi > I did some more
investigation of this problem today. I found that the lmsensor component
implicitly pulls in the libm. As an alternative, I wrote the attached patch
that uses setkey() and encrypt() in libcrypt.so instead. It works on various
linux machines, but I do not know whether it is going to work on other OS.
-Will >From c53c97e1de2d1c7dc0bca64d1906287ff73343c6 Mon Sep 17 00:00:00
2001 From: William Cohen <wcohen@redhat.com> Date: Tue, 9 Jul 2013 22:37:27
-0400 Subject: [PATCH] Avoid using libm.so for ctests/shlib because of
implicit use in some components The lmsensors component can implicitly pull
in libm.so into the executable. Unfortunately, the ctests/shlib test expects
that libm.so is not loaded and will fail because there is no change in the
count of shared libraries. The patch uses libcrypt.so library setkey and
encrypt functions to test PAPI_get_shared_lib_info( ) instead of libm.so
library pow function.
2013-07-09
* bdc9b34b .../tests/perf_event_amd_northbridge.c:
Perf_event_amd_northbridge_test: Use buffer event_name instead of
uncore_event The variable uncore_event is initialized to NULL and is never
changed during execution of the test. PAPI_add_named_event fails and the
event set cannot be started. The correct event name is stored in event_name,
replacing all occurrences of uncore_event with event_name therefore fixes the
problem metioned above.
2013-07-08
* a1678388 src/components/micpower/linux-micpower.c: micpower: Fix output in
native_avail and component_avail. It uses cmp_info.name, not .short_name?
Native Events in Component: mic-power Name: mic-power
Component for reading power on Intel Xeon Phi (MIC) Should both match what
is prepended to event names, so change .name from mic-power to micpower.
* e0582f2d src/components/micpower/linux-micpower.c: Micpower: fix a typo
subsystem, not sybsystem...
* c7b357ec INSTALL.txt: INSTALL.txt: update instructions for MIC.
* 34a1124e src/components/perf_event_uncore/tests/Makefile
.../tests/perf_event_amd_northbridge.c: Add perf_event_amd_northbridge test
The test should show how to write a program using AMD fam15h NB with a 3.9
kernel. Once libpfm4 gets updated we can see if it's possible to also have
the test properly run on 3.10 kernels (in that case the regular
perf_event_uncore test should work w/o changes)
* 41b6507c .../perf_event_uncore/tests/perf_event_uncore.c
.../tests/perf_event_uncore_multiple.c: Make perf_event_uncore tests use
PAPI_get_component_index() They were open-coding the component name search
for no good reason.
2013-07-05
* abf38945 src/papi_libpfm4_events.c: avoid having a "default" PMU for the
uncore component on the main CPU component we have a "default" PMU where you
can leave out the PMU part of the event name. This is unnecessary and
sometimes confusing on uncore, so always print the full event name if it's an
uncore PMU.
* b9fe5c3e .../perf_event_uncore/tests/perf_event_uncore.c
.../tests/perf_event_uncore_multiple.c: Update perf_event_uncore tests to
properly fail if they don't have enough permissions
* 32ae1686 .../perf_event_uncore/tests/perf_event_uncore.c:
perf_event_uncore_test : properly use uncore component The sample code was
still hardcoding to component "0" which shouldn't have worked. Thanks to
Claris Castillo for pointing out this problem.
* 59e73b51 src/papi_libpfm4_events.c: have _papi_libpfm4_ntv_name_to_code
properly check pmu_type With the existing code, uncore events were being
found by the perf_event component even when that component has uncore events
distabled.
2013-07-03
* a01394eb .../tests/perf_event_uncore_lib.c: perf_event_uncore: fix ivb
event in uncore test Now that libpfm4 officially supports plain ivb uncore,
make sure the test event we were using matches what libpfm4 supports.
2013-07-01
* f10342a8 src/utils/cost.c: Clean up option handling in papi_cost The
papi_cost used strstr to seach for the substring that matched the option.
this is pretty inexact. Made sure that the options matched exactly and the
option argments for -b and -t were greater than 0. Also make papi_cost print
out the help if there was an option that it didn't understand.
* b5adc561 src/utils/native_avail.c: Clean up option handling for
papi_native_avail Corrected the help to reflect the name of the option
"--noumasks". Print error message if the "-i", "-e", and "-x" option
arguments are invalid. Avoid using strstr() for "-h", use strcmp instead.
Also check for "--help" option.
* 8933be9b src/utils/decode.c: Clean up option handling in papi_decode
papi_decode used strstr() to match options; this can lead to inexact matchs.
The code should used strcmp instead. Make sure command name is not processed
as an option. Also print help iformation is some argument is not understood.
* d94ac43a src/utils/component.c: Improve option matching in papi_component
and add "--help" option
* bb63fe5c src/utils/command_line.c: Add options to papi_command_line man
page and improve opt handling Add options mention in the -h to the man page.
Also improve the matching of the options.
* 09059c82 doc/Makefile src/utils/version.c: Add information for papi_version
to be complete
* 4f2eee8c src/configure src/configure.in: add a --disable-perf-event-uncore
option to configure
2013-06-29
* 901c5cc2 src/components/perf_event/perf_event.c
src/components/perf_event/perf_event_lib.c
.../perf_event_uncore/perf_event_uncore.c...: remove syscalls.h it's no
longer needed
* 4d7e3666 src/Rules.perfmon2 src/components/perfmon2/Rules.perfmon2
src/components/perfmon2/perfmon.c...: move perfmon modules to their own
component directory
* a7e9c5f1 src/Rules.perfctr src/Rules.perfctr-pfm
src/components/perfctr/Rules.perfctr...: move perfctr files to
components/perfctr directory verified that perfctr-x86 still builds and
works perfctr_ppc has all the files to build, but it doesn't work. It looks
like no one has tried to build perfctr-ppc for a very very long time.
2013-06-27
* e9dec1fd src/ctests/hl_rates.c src/papi.h src/papi_fwrappers.c...: debugged
versions of these files
* e282034e src/utils/native_avail.c: native_avail: Fix parse_unit_mask code
Reported by Steve Kaufmann -------------------------- I noticed while
developing a new component that the output from papi_native_avail was
incorrectly presented for the component. I believe this is because the ":::"
prefix is not being taken into account, so the base event name is interpreted
as a unit mask and is prepend with a : before each legitimate unit mask
associated with the event. I think this is just now happening because mine is
the first component that has unit masks. I have include a fix below. The
output of the unit masks by papi_native_avail now appears correctly for my
component. Thanks, Steve
2013-06-26
* ff096786 src/ctests/fork2.c: fork2: Return fork2 test to its old
functionality Once upon a time fork2 did: PAPI_library_init() … if (
fork() == 0) PAPI_shutdown() PAPI_library_init() …
2013-06-25
* 978d0d3d src/examples/PAPI_add_remove_event.c src/papi.c: Modify
PAPI_list_events functionality to match documentation. You can now pass in a
NULL event array and a zero count to get back the valid number of events.
This can then be used to allocate the array and retrieve the exact number of
events. Thanks to Nils Smeds and Alain Miniussi for pointing this out.
* 13c52402 src/examples/PAPI_add_remove_event.c src/papi.c: Modify
PAPI_list_events functionality to match documentation. You can now pass in a
NULL event array and a zero count to get back the valid number of events.
This can then be used to allocate the array and retrieve the exact number of
events. Thanks to Nils Smeds and Alain Miniussi for pointing this out.
* 656e703e src/ctests/zero_fork.c: zero_fork ctest : make documentation match
code
* 96aad0c7 src/ctests/forkexec.c: forkexec ctest : make comments match code
* b7c70953 src/ctests/forkexec4.c: forkexec4 ctest : make comments match the
code
* 7ffb0245 src/ctests/forkexec3.c: forkexec3 ctest : make documentation match
code
* 55ea846c src/ctests/forkexec2.c: forkexec2 ctest: have comments match what
source does
* 7a601e2a src/ctests/Makefile src/ctests/fork2.c: fork2 ctest: remove; was
an exact duplicate of fork
* 9deff49b src/ctests/fork.c: fork ctest: make comments match what file
actually does
2013-06-24
* 2770d2c5 src/components/perf_event/perf_event_lib.c: perf_event: fix
failure on ARM due to domain settings forgot to git add the perf_event_lib.c
file :(
* bf7c4c50 src/components/perf_event/perf_event.c
src/components/perf_event/perf_event_lib.h: perf_event: fix failure on ARM
due to domain settings On Cortex A8 and A9 it's not possible to set
exclude_kernel (hardware does not support it). Make sure the rdpmc detection
code doesn't try to set exclude_kernel.
2013-06-18
* 2b1433d8 src/ctests/all_native_events.c src/ctests/get_event_component.c:
ctests: Skip calling into disabled components. This patch fixes a problem
that was causing two test cases to abort when they were run on a system which
has disabled components. Code was added to check if the component is
disabled and just go to the next component in the list when the check is
true. This prevents calls to code in components which may abort because the
component was unable to initialize itself correctly. Thanks to Gary Mohr and
Chuck LaCasse from Bull for reporting.
2013-06-14
* 1872453c src/testlib/do_loops.c: testlib: don't change the iter count The
first argument to do_misses is an iteration count, for some reason the code
was dividing this in half before doing work. Most places that call do_misses
call it as do_misses ( 1, ...) void do_misses( int n, int bytes ) { {...} n
= n / 2; for ( j = 0; j < n; j++ ) { 1/2 == 0; so our do_misses call was
usually not. Thanks Nils Smeds for reporting.
2013-06-12
* c113e5b6 src/components/infiniband/Makefile.infiniband.in
src/components/infiniband/Rules.infiniband
src/components/infiniband/configure...: Infiniband component: switch over to
weak linking Thnaks to Gary Mohr for the patch.
---------------------------------- The infiniband component needs include
files and libraries from both the infiniband ibmad and ibumad packages. When
these packages are installed on a system, both packages normally install
their files in the same place (includes in /usr/include/infiniband and
libraries in /usr/lib64). The current component configure script allows you
to provide a single include path and a single library path which gets used to
access files from both packages. If these two packages have different
install prefixes (or you are trying to build from install images of each
package which are not located under the same directory) then the configure
script fails because it can not find all the files it needs. These changes
modify the configure script to replace the include and library dir's with an
ibmad_dir and ibumad_dir and then uses the correct packages directory when
looking for includes and libraries from that package. This makes it work
like the cuda and nvml components with respect to configuring how to find
files from a package the component depends on. There are also changes in
this patch file to remove an unneeded variable in the dlopen code to resolve
some defects reported by coverity.
2013-06-11
* d5be5643 src/components/rapl/tests/rapl_basic.c: rapl tests: make the error
messages a little more verbose
* 0c9f1a8c src/run_tests_exclude.txt src/run_tests_exclude_cuda.txt:
run_tests_exclude files: Exclude a template file
------------------------------------------- It also adds the cpi.pbs file to
the list of files to excluded when the tests are run. This file is just a
template and attempts to run it hang the run_tests script on our systems.
-------------------------------------------
* 0a063619 src/run_tests.sh: run_tests.sh: fix exclude check. The script
failed to remove .cu files, this patch fixes the check. Thanks Gary Mohr for
reporting/patching.
2013-06-10
* 87399477 src/components/cuda/linux-cuda.c: cuda component: Address a
coverity issue The library linking code saved return values in a local var
but never used them. Thanks to Gary Mohr for submitting this patch.
* 99b5b685 src/components/coretemp/tests/coretemp_basic.c: coretemp_basic:
update test to properly enumerate events The code was old and was searching
the entire native event list for ones that started with "hwmon". This
updates the test to first find the coretemp component, then enumerate all
events contained within.
* b5c0795b src/components/rapl/tests/rapl_overflow.c: rapl component: address
potential looping issue in test. A rapl component test has a do/while which
only exited when PAPI_add_named_event returned 0 ( and only 0; the PAPI_E*
error codes would not terminate a while( retval ) loop), this felt fragile,
minimal checks are now inplace.
* 4e9484a5 src/components/rapl/tests/rapl_overflow.c: rapl components:
coverity fixes Reported/patched by Gary Mohr -----------------------------
The rapl component also has 1 defect in a test case. The complaint is that
there is code that can never be executed. But this one is not as clear, it
says that you can not exit the do/while loop that preceeds a test of retval
until retval=0 which means the test can never be true. The patch I am
providing is to again remove the if test and its contents. But I am
concerned that the do/while loop preceeding the test could result in a hard
loop that would hang the test case forever. It seems to me like something
should also be done to insure the loop will exit at some point. Here is a
patch that provides at least part of the fix: -----------------------------
* 0a533810 src/components/net/tests/net_values_by_name.c: net components:
coverity fixes Reported/patched by Gary Mohr -----------------------------
The net component has one defect in one of the test cases. The complaint is
that there is code that can never be executed. There is a test to see if
event_count == 0 which can never be true at that place in the code. So I
removed the if statement and its contents. Here is the patch:
-----------------------------
2013-06-07
* b784b063 src/components/nvml/Rules.nvml src/components/nvml/configure
src/components/nvml/configure.in...: nvml: Apply Gary Mohr's dlopen patch.
Move the nvml component over to using the dlopen and weak linking
infrastructure of the cuda component. Thanks, Gary.
* d6505b76 src/components/rapl/utils/rapl_plot.c: rapl: update the rapl_plot
utility Get the event names by enumerating the ones available with the RAPL
component rather than having a hard-coded list.
* 2094c5b1 src/components/rapl/linux-rapl.c: rapl: add better error messages
on component init failure
* d0e668fb src/ctests/Makefile src/ctests/high-level.c
src/ctests/hl_rates.c...: First round of changes to implement a PAPI high
level event per cycle call. Untested.
2013-06-05
* 63074f82 src/components/rapl/linux-rapl.c: rapl: Add Ivb-EP support The
Intel docs are spotty on what is actually supported. They state: 14.7.2 RAPL
Domains and Platform Specificity The specific RAPL domains available in a
platform varies across product segments. Platforms targeting client segment
support the following RAPL domain hierarchy: * Package * Two power planes:
PP0 and PP1 (PP1 may reflect to uncore devices) Platforms targeting server
segment support the following RAPL domain hierarchy: * Package * Power plane:
PP0 * DRAM
2013-05-31
* 31b4702d src/cpus.c: cpus.c: Don't run init_thread/shutdown_thread for
disabled components.
2013-05-29
* c48087d2 ChangeLogP511.txt RELEASENOTES.txt: Grab the updated ChangeLog
from 5.1.1 Create a ChangeLog and update RELEASENOTES for a 5.1.1 release.
2013-05-24
* d1c8769e src/components/perf_event/tests/Makefile
src/components/perf_event/tests/event_name_lib.c
.../perf_event/tests/perf_event_user_kernel.c: Add perf_event user/kernel
domain test This will be useful if/when we start handling domains properly.
* 89e1aeba src/components/perf_event/tests/Makefile
src/components/perf_event/tests/event_name_lib.c
src/components/perf_event/tests/event_name_lib.h...: Add perf_event offcore
response test Does a quick check to see if offcore response events are
working.
* bda86616 .../perf_event_uncore/perf_event_uncore.c
src/ctests/get_event_component.c src/papi_internal.c: Some more ctest fixes
involving disabled components. We enforce disabled components sometime in
the PAPI routines and sometimes in the components themselves. A bit
confusing. It is tough with perf_event and perf_event_uncore because we
share libpfm4 by both, so the naming library for perf_event_uncore will be
active even if the component is disabled, which can cause some confusing
results if your test code ignores PAPI_ENOCMP error messages and accesses a
disabled component anyway. This at least fixes our test cases, we might have
to revisit this later.
* b596621e doc/Doxyfile-common papi.spec src/Makefile.in...: Bump version
numbers Call this 5.2.0.0 simple because its greater than (and some
components are completely incompatible with) 5.1.1
* eb77a91e .../perf_event_uncore/perf_event_uncore.c src/papi.c: Disallow
enumerating events on disabled components. This was causing segfaults on
tests where enumeration was trying to enumerate uncore events on machines w/o
uncores.
* 4e991a8a .../perf_event/tests/perf_event_system_wide.c:
perf_event_system_wide: SKIP instead of FAIL if we don't have proper
permissions
* 7654bb1f src/Makefile.inc src/components/perf_event/tests/Makefile
.../perf_event/tests/perf_event_system_wide.c...: move the perf_event
specific tests to be with their component This means the perf_event tests
will only be run if perf_event is enabled
* d82e343f src/ctests/perf_event_uncore_multiple.c:
ctests/perf_event_uncore_multiple: Improve this test a bit
* b1a594bf src/perf_events.c src/sys_perf_event_open.c: Remove the no-longer
needed perf_events files Now we use the versions in the
components/perf_event directory
* a9a277f3 src/Makefile.in src/Makefile.inc src/configure...: Split up
CPUCOMPONENT configure variable Now it is CPUCOMPONENT_NAME CPUCOMPONENT_C
CPUCOMPONENT_OBJ This allows having setups with no CPUCOMPONENT set
(perf_event used as a component) while keeping backward compatible with
non-component CPU components. This has been tested on perf_event and
perfctr. It might break other architectures, so test if you can.
* 69e29526 src/configure src/configure.in: configure: have --with-components
append comonents to existing value This allows configure to earlier set the
components value to include "perf_event" if detected and then later append
the values passed in with --with-components
* 9d28df4c src/components/perf_event/Rules.perf_event
src/components/perf_event/perf_event.c
src/components/perf_event/perf_event_lib.c...: add perf_event and
perf_event_uncore components This adds perf_event as a standalone component.
Currently it is not compiled or built, some changes need to be made to the
build system before this will work.
2013-05-21
* ea996661 src/components/cuda/linux-cuda.c: eliminate warnings of unused
vars
* 691bf114 src/components/cuda/linux-cuda.c: eliminate warnings of unused
vars
* 221bfdab src/components/cuda/linux-cuda.c
src/components/cuda/tests/HelloWorld.cu: Problem with cleanup_eventset():
after destroying the CUDA eventset, update_control_state() is called again
which operates on the already destroyed eventset.
2013-05-17
* 84925f50 src/components/cuda/linux-cuda.c: When adding multiple CUDA events
to an event set, PAPI_add_event() error 14 (CUPTI_ERROR_NOT_COMPATIBLE) is
being raised from the CUPTI library. Turns out that the CUDA update control
state wasn't cleaning the event set up properly before adding new events.
It's fixed now.
* 2337aa3a src/perf_events.c: perf_event: allow running with
perf_event_paranoid is 2 perf_event_paranoid set to 2 means allow user
monitoring only (no kernel domain). The code before this mistakenly disabled
all events in this case. Also set the allowed domains to exclude
PAPI_DOM_KERNEL.
2013-05-16
* 617d9fbb src/papi_events.csv: papi_events.csv Revert a little mishap in
adding ivbep support Somehow the contents of papi_hl.c ended up in the
events file.
* 2aff4596 src/papi_events.csv: Add identifier for ivb_ep
* 1810ddf9 src/papi_libpfm4_events.c src/papi_libpfm4_events.h
src/perf_events.c: papi_libpfm4_events: allow specifying
core/uncore/os_generic PMUs This allows you to specify you only want your
perf_event/libpfm4 based component to only export the PMU types you want.
Now we can have an uncore-only component.
* 6554f3f0 src/papi_libpfm4_events.c: papi_libpfm4_events.c: only enable
presets for component 0 If we have multiple events using libpfm4, we only
want to load the presets if it is component 0.
* 6a4a4594 src/papi.c: PAPI_get_component_index() was matching names
improperly For example, it was matching perf_event and perf_event_uncore as
the same component.
* 1b94e157 src/papi_hl.c: papi_hl.c : fix IPC calculation I broke it a while
back while trying to clear out use of MHz. The code was uncommented and very
confusing. It is slightly better now.
* 92d4552e src/papi_libpfm4_events.c src/papi_libpfm4_events.h
src/perf_events.c: papi_libpfm4_events: code changes to allow multiple
component access the PAPI libpfm4 code has been modified to allow multiple
users at once. This will allow multiple components to use libpfm4, for
example a CPU component and an uncore component.
* 7902b30e src/cpus.c: cpus: fix debug compile I always forget to compile
with --with-debug and miss changes in the DEBUG statements.
2013-05-15
* 7ddc05ff src/cpus.c src/cpus.h: cpus.c: Add reference count to cpu
structure It is possible to have multiple eventsets all attached to the same
CPU, as long as only one eventset is running at a time. At EventSet cleanup,
PAPI would free the CpuInfo_t structure even if other EventSets were still
using it. This patch adds a reference count to the structure and only frees
it after the last user is cleaned up. I also fixed a few locking bugs,
hopefully I didn't introduce any new ones.
* 6a61f9a2 src/cpus.c: more cleanup of the cpus.c file mostly formatting and
added comments.
* 710d269f src/cpus.c src/cpus.h src/papi.c...: cleanup cpus.h It had a lot
of extraneous stuff in it. Also make sure it only gets included in files
that need it.
* 422226c9 src/papi.c: papi.c: add some extra debug messages
* b1297058 src/cpus.c: Clean up cpus.c a bit Tracking down a segfault in the
cpu attach cleanup code.
* 7b6023cf src/ctests/perf_event_system_wide.c:
ctests/perf_event_system_wide: much improved output It segfaults at the end
though, unclear if this is a bug in the test or a bug in PAPI. Will
investigate.
* 38397aa3 src/components/cuda/configure src/components/cuda/configure.in
src/components/cuda/linux-cuda.c...: Cuda component: Update library search
path From Gary Mohr: It turns out that with the changes I gave you the path
to the libcuda.so library is still hard coded to /usr/lib64. This assumes
that the NVIDIA-Linux package is installed on the system where the build is
being done. In Bull's case (and probably other users also) this is not
always the case. To add the flexibility we need, I have added a new
configure argument to the cuda configure script. The new argument is
"--with-cudrv_dir" and it allows the user to specify where the cuda driver
package (ie: NVIDIA-Linux) to be used for the build can be found. This new
argument is optional and if not provided a value of "/usr" will be used. This
allows existing configure calls to continue to work like before.
* f8873d1c src/ctests/perf_event_system_wide.c:
ctests/perf_event_system_wide: clean up the output a lot Still working on
understanding it.
* ebf20589 src/ctests/perf_event_system_wide.c: perf_event_system_wide:
testing various DOMAIN and GRANULARITY settings pushing the limits of
PAPI/perf_event trying to see why system-wide measurement doesn't work.
2013-05-14
* 0c1ef3f5 src/components/cuda/linux-cuda.c: CUDA component: Update
description field Also removes a strcpy in the init code, which overwrote
the name field. Thanks to Gary Mohr
* 474fc00e src/ctests/perf_event_uncore_lib.c: Add AMD fam15h northbridge
event to ctests/perf_event_uncore_lib.c
2013-05-13
* cf56cdac src/perf_events.c: perf_event component: update error returns
This passes more error return values back to PAPI. Before this change a lot
of places were hardcoded to PAPI_EPERM even if sys_perf_event_open() was
reporting a different error.
* c824471b src/ctests/Makefile src/ctests/perf_event_system_wide.c
src/ctests/perf_event_uncore.c...: Update the perf_event specific tests.
This adds a few more uncore tests, which are currently showing some bugs in
the implementation. The tests all need root permissions to run, so should
default to "SKIPPED" for most users.
2013-05-08
* e0204914 src/configure src/configure.in: Force the use of pthread_mutexes
on ARM This lets the system libraries worry about the best way to define
mutexes, rather than trying to hand-code in assembly around all of the
various issues there are with atomic instructions in the ARM architecture.
It might make sense to enable this for *all* Linux architectures, but for now
just do it for ARM.
* f21b1b27 src/linux-lock.h: Commit 59d3d7584b2925bd05b4b5d0f4fe89666eb8494a
removed the definition of mb(). mb() was defined as rmb(). This just
corrects it back. (Note from VMW -- this fixes some things, but ARM still
won't build on a Cortex A9 pandaboard due to the use of the "swp"
instruction. Proper fix is probably to enforce posix-mutexes on ARM)
2013-05-06
* 913f0795 src/components/nvml/configure src/components/nvml/configure.in:
NVML: Update wording for configure options. Thanks for pointing out the
ambigous wording, Heike.
* 81a86c2b src/components/infiniband/Rules.infiniband
src/components/infiniband/linux-infiniband.c
src/components/infiniband/tests/Makefile: Infiniband component: use
dlopen/dlsym for symbols Apply Gary Mohr's patch to switch the infiniband
component over to dl* with the same motivations as the cuda component.
2013-05-02
* 2e6bcb2a src/utils/native_avail.c: Add two command line switches: -i
EVENTSTR includes only events whose names contain EVENTSTR; -x EVENTSTR
excludes all events whose names contain EVENTSTR. These two switches can be
combined, but only one string per switch can be used. This allows you to, for
example, filter events by component name, or eliminate all uncore events on
Sandy Bridge…
2013-05-01
* 3163cc83 src/ctests/perf_event_uncore.c: ctests/perf_event_uncore: add
IvyBridge support this needs an updated libpfm4 to work
2013-04-30
* 55c89673 src/examples/add_event/Papi_add_env_event.c
src/examples/overflow_pthreads.c: Examples: Missed two instances of %x printf
formating.
2013-04-29
* b3c5bd47 src/components/appio/tests/appio_list_events.c
src/components/appio/tests/appio_values_by_code.c
src/components/appio/tests/appio_values_by_name.c...: Address TRAC 174: Let
printf do the formatting https://icl.cs.utk.edu/trac/papi/ticket/174 174:
PAPI's debuggin/info output should use %# conversions for octal and hex
------------------------+-------------------- Reporter: sbk@… |
Owner: Type: enhancement | Status: new Priority: normal |
Component: All Version: HEAD | Severity: normal Keywords:
| ------------------------+-------------------- Email sent to James
Ralph: Seeing your latest change reminded me: Anytime there is a value
issued in hex or octal the "%#" conversion should be used so the value is
always preceded with a "0" for octal or a "0x" for hex. Otherwise when a
value is printed one can not tell the base it is in (one shouldn't have to
rely on internal knowledge of the code or the context to tell). For variables
that are pointers the "%p" conversion can be used (this will always use an
hex syntax). It would be nice to apply this to all PAPI print statements in
their entirety.
2013-04-25
* 87ec9286 src/components/vmware/Rules.vmware: Rules.vmware: Use $(LDL) no
-ldl Minor cleanup, but configure sets it, so why not use it.
2013-04-26
* 8dddd587 src/papi_hl.c: papi_hl: Use PAPI_get_virt_usec() for process time
The code was using cycles / MHz which is not guaranteed to work on modern
machines. It also was sometimes using (instructions / estimated IPC) / MHz
which hopefully isn't necessary for any machine PAPI currently supports.
Instead use PAPI_get_virt_usec() which should give the right value.
2013-04-25
* 9dd36088 src/ctests/perf_event_uncore.c: ctests/perf_event_uncore: make
more modular Cleans up the code to make it easier to add tests for
architectures other than SandyBridge-EP. I was doing this so I could add
support for IvyBridge but it turns out neither Linux nor libpfm4 supports
uncore on IvyBridge yet. hmmm.
* 52ff0293 src/components/cuda/Rules.cuda: Rules.cuda: The cuda component
now depend on the dynamic linking loader and on some systems one has to
explicitly link to it. Add $(LDL) to LD_FLAGS, configure sets it if we need
it.
* 97a4a5ea src/components/cuda/Rules.cuda src/components/cuda/linux-cuda.c
src/components/cuda/tests/Makefile: Cuda component enhancement.
---------------- From Gary's submission--------------------------------- The
current packaging of the cuda component in PAPI has a fairly unfriendly side
effect. When PAPI is built with the cuda component, then that copy of PAPI
can only be used on systems where the cuda libraries are installed. If it is
installed on a system without these libraries then all PAPI services fail
because they have references to libraries which can not be found. Even
papi_avail which you would think has nothing to do with cuda reports the
error. This issue significantly complicates the delivery and install of the
PAPI package on large clusters where some of the nodes have NVIDIA GPU's (and
the cuda libraries to talk to them) and other nodes do not have GPU's (and
therefore no software to access them). I have been working with the help of
Phil Mucci to eliminate this dependency so that a copy of PAPI built with a
cuda component could be installed on all nodes in the cluster and if the node
had NVIDIA GPU's (and libraries available) then the cuda component would get
enabled and could be used. If the node did not have the hardware or the
access libraries were not available, then the cuda component would just
disable itself at component initialization so it could not be used (but all
other PAPI services would still work). Phil has provided some gentle
prodding and lots of valuable suggestions to assist this effort. I now think
that I have a working version of this capability and am ready to share it
with the community.
----------------------------------------------------------------------- Many
thanks to Gary Mohr and Phil Mucci for this much needed functionality.
2013-04-23
* 99c8e352 src/papi_internal.c: papi_internal.c: Print an eventcode in hex vs
decimal. Thanks, Gary Mohr.
2013-04-22
* 1fc5dae2 src/run_tests.sh: The test for determining whether to run valgrind
was backwards. Correcting that allow the run_test.sh script to stay the same
and one just needs to define "VALGRIND=yes" (or any non-null string) to make
run_test.sh use valgrind. --- src/run_tests.sh | 6 ++---- 1 file changed, 2
insertions(+), 4 deletions(-) diff --git a/src/run_tests.sh
b/src/run_tests.sh index d1ce205..9337ff2 100755 --- a/src/run_tests.sh +++
b/src/run_tests.sh @@ -19,10 +19,8 @@ else export TESTS_QUIET fi -if [
"x$VALGRIND" = "x" ]; then -# Uncomment the following line to run tests using
Valgrind -# VALGRIND="valgrind --leak-check=full"; - VALGRIND=""; +if [
"x$VALGRIND" != "x" ]; then + VALGRIND="valgrind --leak-check=full"; fi
#CTESTS=`find ctests -maxdepth 1 -perm -u+x -type f`; --
2013-04-19
* 4cf16234 src/components/README src/components/bgpm/README
src/components/coretemp_freebsd/README...: Restructure README files for
components so that the file in the components directory doesn't document
individual component details. Add README files to each component directory
that requires further installation detail. Update RAPL instructions to
capture how to enable reading the MSRs. These files are supposedly configured
with Doxygen markup, but I don't think the master README ever got built. It
probably should.
2013-04-17
* bf75d226 src/components/cuda/tests/HelloWorld.cu: cuda/tests/HelloWorld.cu:
workaround a segfault. Report from Gary Hohr
I was running the Cuda test case on a system which did not actually have any
NVIDIA GPU's installed on it (but the cuda software was installed and papi
was built with the cuda component). I modified the test case to put an real
cuda event in the source (as suggested in the source). When I run the test
case the cuda component gets disabled in PAPI_library_init (because
detectDevice function can not find any GPU's) which is the correct behavior.
The test case then calls PAPI_event_name_to_code which failed because the
cuda component was disabled. The test case then created an event set and
called PAPI_add_events with an empty list of events to be added. This led to
a segfault somewhere inside libpfm4. The attached patch makes some minor
changes to protect against this problem. I noticed this test case does not
use the PAPI test framework utilities (test_xxxx functions) so I did not
modify the test to use them.
2013-04-15
* 457bfd74 src/components/cuda/linux-cuda.c: When creating two event sets -
one for the CUDA and one for the CPU component - the order of event set
creation appears crucial. When the CPU event set has been created before the
CUDA event set then PAPI_start() for the CUDA event set works fine. However,
if the CUDA event set has been created before the CPU event set, then
PAPI_start(CUDA_event_set) forces the CUDA control state to be updated one
more time, even if the CUDA event set has not been modified. The CUDA control
state function did not properly handle this case and hence cause PAPI_start()
to fail. This has been fixed.
* 807120b6 src/components/cuda/linux-cuda.h: linux-cuda.c
2013-03-28
* 7b0eec7a src/run_tests.sh: run_tests.sh: further refine component test find
Exclude *.cu when looking for component tests.
2013-03-25
* 6a40c8ba src/run_tests.sh: run_tests.sh: File mode changes. run_tests.sh
is now expected to run from the install location in addition to src. The
script tried to remove execute from *.[c|h], now it just excludes *.[c|h]
from the find commands.
2013-03-18
* 2ba9f473 src/perfctr-x86.c: perfctr: don't read in event table multiple
times papi_libpfm3_events.c now reads in the predefined events, we don't
also need to do this in perfctr setup_x86_presets()
* 326401b1 src/perfctr.c: Fix segfault in perfctr.c The preset lookup uses
the cidx index, but in perfctr.c we weren't passing a cidx value (it was
being left off). The old perfctr code plays games with defining extern
functions so the compiler wasn't giving us a warning.
2013-03-14
* 50130c6f src/components/bgpm/L2unit/linux-L2unit.c src/linux-bgq.c: If a
counter is not set to overflow (threshold==0; happens when PAPI_shutdown is
called) then we do not want to rebuild the BGPM event set, even if the event
set has been used previously and hence "applied or attached". Usually if an
event set has been applied or attached prior to setting overflow, the BGPM
event set needs to be deleted and recreated (which implies malloc() from
within BGPM). Not so, though, if threshold is 0 which is the case when
PAPI_shutdown is called. Note, this only applies to Punit and L2unit, not
IOunit since an IOunit event set in not applied or attached.
2013-03-13
* 1a143003 src/components/bgpm/IOunit/linux-IOunit.c
src/components/bgpm/IOunit/linux-IOunit.h
src/components/bgpm/L2unit/linux-L2unit.c...: Overflow issue on BG/Q
resolved. Overflow with multiple components worked; overflow with multiple
components and multiple events did not work as supposed to.
* 42741a40 src/components/cuda/Rules.cuda: Added one more library to linker
command.
2013-03-12
* 1431eb3f src/components/nvml/Makefile.nvml.in
src/components/nvml/Rules.nvml src/components/nvml/configure...: NVML
component: build system work Adopt the cuda component's method for
specifying library location.
2013-03-11
* ce66feac src/components/mx/linux-mx.c: mx component: Modernize init
routine. Add component index to _mx_component_init()s signarure and set the
bit in component info.
* 1c1bc177 src/components/cuda/Makefile.cuda.in
src/components/cuda/Rules.cuda src/components/cuda/configure...: Resolve
configure issues for CUDA component.
2013-03-07
* f3572537 src/linux-common.c src/linux-memory.c: Fix the build on
Linux-SPARC I dug out an old SPARC machine and fixed the PAPI build on it.
* 2c7f102c src/perf_events.c: More comprehensive sys_perf_open to PAPI error
mappings This tries to cover more of the errors returned by sys_perf_open
and map them to better results. EINVAL is a problem because it can mean
Conflict as well as Event not found and many other things, so it's unclear
what to do with it.
* 299070ef src/perf_events.c src/sys_perf_event_open.c: Return proper error
codes for sys_perf_event_open For some reason on x86 and x86_64 we were
trying to set errno manually and thus over-writing the proper errno value,
causing all errors to look like PAPI_EPERM This removes that code, as well
as adds code to report ENOENT as PAPI_ENOEVENT. With this change, on IVY
this happens which looks more correct. ./utils/papi_command_line
perf::L1-ICACHE-PREFETCHES Failed adding: perf::L1-ICACHE-PREFETCHES because:
Event does not exist command_line.c PASSED
2013-03-06
* baa557ca src/papi_libpfm4_events.c src/papi_user_events.c: Coverity fixes:
Coverity pointed out that there was a case where load_user_eent_table() could
leak memory. The change in the location of the papi_free(foo) ensures that
the allocated memory is freed. Coverity pointed out one path through the
code in _papi_libpfm4_ntv_code_to_descr() that did not free up memory
allocated in the function. Added a free on the path in free up that memory.
Thanks Will Cohen.
2013-02-14
* 395b7bc7 src/Makefile.inc src/components/README
src/components/appio/tests/Makefile...: Add component tests' to the
install-[all|tests] target. Thanks to Gary Mohr. ------------------- This
makes a fairly small change to src/Makefile.inc to add logic that adds a new
install-comp_tests target which calls the install target for each component
being built. This new target is listed as a dependency on the install-tests
target so it will happen when the 'install-all', 'install-tests', or
'install-comp_tests' targets are used. A note about this change, I am not
real familiar with the auto make and auto conf tools. This change was enough
to make it work for me but if there is another file that should also be
changed for this modification, please help me out here. The patch also adds
install targets to the Makefiles for all of the components which have 'tests'
directories and updates the README file which talks about how to create
component tests. Another note, I only compile with a couple of components
(ours, rapl, and example) so if I fat fingered something in one of the other
components Makefiles I would not have noticed. Please keep me honest and make
sure you compile with them all enabled. Thanks for adding this capability
for us. Gary --------------------------- Makefile.inc: Add run_tests and
friends to install-tests target. Component test Makefiles' get their install
location to mirror what runtests expects.
2013-03-04
* 448d21ab src/components/rapl/linux-rapl.c: Remove a stray debug statement.
Thanks to Harald Servat for catching this.
2013-03-01
* df1a75cc src/utils/command_line.c: Wrestled some horribly convoluted
indexing into shape. The -u and -x options now print as expected (I think).
2013-01-31
* b0f5f4d6 src/components/nvml/linux-nvml.c: linux-nvml.c: Fix type warning.
CUDA and NVML have an signed vs unsigned thing going on in their returned
device counts, cast away the warning.
2013-01-29
* 8490b4ee src/papi.c: General doxygen cleanup: remove all "No known bugs"
messages; correct and cleanup examples for PAPI_code_to_name and
PAPI_name_to_code
2013-01-23
* 89e45a9b src/linux-memory.c src/linux-timer.c: ia64 fixes. Thanks to Tony
Jones <tonyj@suse.de> for patches.
2013-01-16
* 23e0ba2d src/components/nvml/linux-nvml.c: nvml component: cleanup a memory
leak We did not free a buffer at shutdown time.
2013-01-15
* f3db85fc src/papi.h: papi.h bump version number.
* dfa80287 src/buildbot_configure_with_components.sh: Buildbot configure
script. Add cuda and nvml components, if configured, to the buildbot
coverage test. Note: Script now checks for existance of Makefile.cuda and
then Makefile.nvml so see if it can build the cuda component and then if it
can build the nvml component.
* cf416e27 src/threads.c: Cleaned up compiler warning (gcc version 4.4.6)
* 59cbc8fc src/components/bgpm/CNKunit/linux-CNKunit.c
src/components/bgpm/IOunit/linux-IOunit.c
src/components/bgpm/L2unit/linux-L2unit.c...: Cleaned up compiler warnings on
BG/Q (gcc version 4.4.6 (BGQ-V1R1M2-120920))
2013-01-14
* 3af71658 .../build/lib.linux-x86_64-2.7/perfmon/__init__.py
.../lib.linux-x86_64-2.7/perfmon/perfmon_int.py
.../build/lib.linux-x86_64-2.7/perfmon/pmu.py...: libpfm4: remove extraneous
build artifacts. Steve Kaufmann reported differences between the libpfm4 I
imported into PAPI and the libpfm4 that can be attained with a git clone
git://perfmon2.git.sourceforge.net/gitroot/perfmon2/libpfm4 Self: Do libpfm4
imports from a fresh clone of libpfm4.