From: Maynard J. <may...@us...> - 2014-08-07 21:07:22
|
On 08/07/2014 12:54 PM, Andreas Arnez wrote: > On Tue, Aug 05 2014, Maynard Johnson wrote: > >> Andreas, those changes in the patch below look fine, but could you >> please just add a "Signed-off-by:" line to make it official. > > Well, the patch was intended for illustration only since operf still > failed. Nevertheless, I'm attaching a revised version of the patch > (broken up into a 3-part series), because it is certainly needed for > s390. Additional fixes may have to come on top. > >>> [root@p23lp54 arnez]# operf --verbose=all -s >>> Using samples dir /root/arnez/oprofile_data/samples >>> kernel_start = 0; kernel_end = 778848 >>> operf_record ctor using output fd 7 >>> calling sigaction >>> calling setup >>> operf_record::setup() for system-wide profiling >>> op_get_process_info >>> calling perf_event_open for pid -1 on 24 cpus >>> perf_event_open failed: No such file or directory >> This is the perf_event_open syscall failing with ENOENT when we pass "-1" for both >> 'pid' and 'cpu' arguments for when we want to do system-wide profiling. You'd have >> to look at the kernel to see why it fails (probably start with arch/s390/kernel/perf_cpum_sf.c). >> I would bet a non-system-wide profile would work OK (e.g., 'operf /bin/true'). > > No, I tried that as well, with the same result. > > After some more digging, here's what I found out for s390: > > * First, back to the linker's complaint at a C++ static string > initializer when linking ocount with -lrt and without -lpthread. Now > I realized that removing -lrt works as well. It seems that ocount > doesn't actually need librt (anymore), right? Thanks for the tip, Andreas. That made me do some digging of my own and I've found that the clock_* functions have been moved into libc in GLIBC 2.17. I'll code a fix to configure.ac to check for this so we only link to librt as needed. > > * With "-e HWSAMPLING", ocount fails at perf_event_open. This is > because the s390 kernel forbids PERF_TYPE_RAW in combination with the > exclude_hv attribute field being set. Without "-e", ocount doesn't > set the flag and seems to work. -- Why does ocount behave differently > in these cases? Thanks for the debugging details. I committed the following change on July 7: Make sure hypervisor is excluded from ocount and operf Since we have no interface support in the event specification to allow the user to select or de-select counting events in hypervisor, and also since the output of ocount and opreport do not support the concept of hypervisor, we should exclude hypervisor from counting and profiling. There's a bug in the current code such that the user may or may not get hypervisor events included. This patch explicitly excludes hypervisor. Apparently, I neglected making the corresponding change for the default event. I will make a patch to fix that, too. > > * operf always fails at perf_event_open, because it specifies the wrong > combination of "type" and "config" fields. The combinations supported > by the kernel are: > > type | config > -------------------+---------------------------------- > PERF_TYPE_RAW | PERF_EVENT_CPUM_SF (0xb0000) > PERF_TYPE_RAW | PERF_EVENT_CPUM_SF_DIAG (0xbd000) > PERF_TYPE_HARDWARE | PERF_COUNT_HW_CPU_CYCLES (0) > > But operf provides type=PERF_TYPE_RAW and config=0. If the > s390-specific event definition file contains "event:0xB0000" instead > of "event:0", operf works, but then ocount fails. The combinations > supported by the kernel obviously differ between counting and > profiling. -- How should we go about reflecting this in oprofile? I'll write a patch for you to test -- something that will work exclude_hv = 1 (which means using PERF_TYPE_HARDWARE instead of PERF_TYPE_RAW). -Maynard > > So, while the patches below are certainly needed, oprofile still fails > on s390. Any ideas how to fix the problems above? > > -- >8 -- > From f7178d46f4c9126fe77ed313a4d27eeede971f49 Mon Sep 17 00:00:00 2001 > From: Andreas Arnez <ar...@li...> > Date: Thu, 7 Aug 2014 17:37:07 +0000 > Subject: [PATCH 1/3] No longer link ocount with librt. > > Linking with librt but without libpthread may cause linker errors on > certain platforms, and it seems that nothing from librt is used at > all (anymore). > > Signed-off-by: Andreas Arnez <ar...@li...> > --- > pe_counting/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/pe_counting/Makefile.am b/pe_counting/Makefile.am > index c46fd74..3565d65 100644 > --- a/pe_counting/Makefile.am > +++ b/pe_counting/Makefile.am > @@ -19,7 +19,7 @@ AM_CXXFLAGS = @OP_CXXFLAGS@ > AM_LDFLAGS = @OP_LDFLAGS@ > > bin_PROGRAMS = ocount > -ocount_LDADD = -lrt ../libpe_utils/libpe_utils.a \ > +ocount_LDADD = ../libpe_utils/libpe_utils.a \ > ../libpe_utils/libpe_utils.a \ > ../libop/libop.a \ > ../libutil/libutil.a \ > |