From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-return-24923-listarch-systemtap=sources.redhat.com@sourceware.org>
Received: (qmail 1413 invoked by alias); 13 Sep 2016 15:26:22 -0000
Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap.sourceware.org>
List-Subscribe: <mailto:systemtap-subscribe@sourceware.org>
List-Post: <mailto:systemtap@sourceware.org>
List-Help: <mailto:systemtap-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-owner@sourceware.org
Received: (qmail 1137 invoked by uid 48); 13 Sep 2016 15:26:09 -0000
From: "mcermak at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: systemtap@sourceware.org
Subject: [Bug runtime/10234] clean up aggregate hard-coded logic
Date: Tue, 13 Sep 2016 15:26:00 -0000
X-Bugzilla-Reason: AssignedTo
X-Bugzilla-Type: changed
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: mcermak at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: systemtap at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-10234-6586-RVGblzH6eZ@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-10234-6586@http.sourceware.org/bugzilla/>
References: <bug-10234-6586@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2016-q3/txt/msg00292.txt.bz2

https://sourceware.org/bugzilla/show_bug.cgi?id=3D10234

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcermak at redhat dot com

--- Comment #3 from Martin Cermak <mcermak at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #0)
> the runtime makes a number of unfortunate assumptions about aggregate
> objects:
>=20
> - that all of count/min/max/sum should be tracked

The @variance() operator, introduced per PR11308, comes with a mechanism
tracking the stat operators used with given global within the script.  This
mechanism is being used to skip variance calculations if they are not neede=
d.=20
Variance is significantly more expensive than min or max, so the most
beneficial optimization already is in place.  Looking at min, max, sum and
count, I think the effect of optimizing them out is close to unmeasurable:

I've been repeatedly running following command on my workstation:

=3D=3D=3D=3D=3D=3D=3D
rm -rf ~/.systemtap; for k in `seq 1 500`; do stap -t -g --suppress-time-li=
mits
-e 'global x probe oneshot{ for(i; i<40000; i++) x<<<i println(@count(x)) }=
' |
sed 's/avg//g' | awk -F\/ '/^begin/ {print $2/1e3}'; done | awk '{ total +=
=3D $1;
count++ } END { print total/count }'
=3D=3D=3D=3D=3D=3D=3D

and comparing results related to presence versus absence of the following
patch:

=3D=3D=3D=3D=3D=3D=3D
diff --git a/runtime/stat-common.c b/runtime/stat-common.c
index e58b1c2..70a46ea 100644
--- a/runtime/stat-common.c
+++ b/runtime/stat-common.c
@@ -306,11 +306,13 @@ static void __stp_stat_add(Hist st, stat_data *sd,
int64_t val)
                sd->_M2 =3D 0;
        } else {
                sd->count++;
+               /*
                sd->sum +=3D val;
                if (val > sd->max)
                        sd->max =3D val;
                if (val < sd->min)
                        sd->min =3D val;
+               */
                /*
                 * Following is an optimization that improves performance
                 * in case @variance() isn't used with given global.
$
=3D=3D=3D=3D=3D=3D=3D

The times I got having these lines commented out were: 879, 815, 820, 830, =
925,
741, 834, 890.
The times I got not having these lines commented out: 1049, 1010, 1047, 953,
976.

Based on the above I'd say, it might make sense to conditionally optimize t=
his
whole block out if respective stat ops are not in use.  My nose tells me th=
at
doing more targeted optimizations would not be beneficial.  Thoughts?

--=20
You are receiving this mail because:
You are the assignee for the bug.