From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20837 invoked by alias); 30 Jul 2014 20:38:25 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 20814 invoked by uid 48); 30 Jul 2014 20:38:21 -0000 From: "i.ucar86 at gmail dot com" To: systemtap@sourceware.org Subject: [Bug runtime/17216] New: perf.hw counters misbehaviour Date: Wed, 30 Jul 2014 20:38:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: i.ucar86 at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q3/txt/msg00088.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17216 Bug ID: 17216 Summary: perf.hw counters misbehaviour Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime Assignee: systemtap at sourceware dot org Reporter: i.ucar86 at gmail dot com Created attachment 7732 --> https://sourceware.org/bugzilla/attachment.cgi?id=7732&action=edit Two scripts that reproduce the bug The following happens, at least, with perf.hw.instructions and perf.hw.cpu_cycles. I think it's a runtime bug, but I'm not sure. Check the attachment, please. It contains two files, perf_good.stp and perf_bad.stp. They serve the same purpose: counting the number of instructions and CPU cycles of a given executable (/usr/bin/find). And they are essentially equal, except that the counters are declared in different order. As one could expect, perf_good.stp prints the good result (I mean, the same as the kernel tool "perf") while perf_bad.stp prints a bad result (specifically, the inverse result: instructions as cycles and cycles as instructions). How to reproduce it? The following commands do the trick (the output numbers are fake and are provided for illustrative purposes only): $ perf stat find /usr/bin -name "l*" -printf "%h/%f %s %Cx %Ck%CM %Y\n" instructions: 25, cycles: 15 $ stap perf_good.stp -c "find /usr/bin -name \"l*\" -printf \"%h/%f %s %Cx %Ck%CM %Y\n\"" instructions: 25, cycles: 15 $ stap perf_bad.stp -c "find /usr/bin -name \"l*\" -printf \"%h/%f %s %Cx %Ck%CM %Y\n\"" instructions: 15, cycles: 25 Here is some information about my system: $ uname -a Linux tombstone 3.14.9-200.fc20.x86_64 #1 SMP Thu Jun 26 21:40:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ stap -V Systemtap translator/driver (version 2.5/0.158, rpm 2.5-2.fc20) Copyright (C) 2005-2014 Red Hat, Inc. and others This is free software; see the source for copying conditions. enabled features: AVAHI LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR TR1_UNORDERED_MAP NLS DYNINST JAVA LIBVIRT LIBXML2 Please, don't hesitate to ask for more information if you need. -- You are receiving this mail because: You are the assignee for the bug.