Re: S390 support to be removed from next oprofile release

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 <[email protected]>
> 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 <[email protected]>
> ---
>  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 \
> 


------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk