From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4567 invoked by alias); 25 Feb 2009 02:53:55 -0000 Received: (qmail 4547 invoked by uid 22791); 25 Feb 2009 02:53:54 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Feb 2009 02:53:47 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1P2rhZ3019642; Tue, 24 Feb 2009 21:53:43 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1P2rhP9026736; Tue, 24 Feb 2009 21:53:43 -0500 Received: from ton.toronto.redhat.com (ton.yyz.redhat.com [10.15.16.15]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1P2rg6Y011712; Tue, 24 Feb 2009 21:53:42 -0500 Received: from ton.toronto.redhat.com (localhost.localdomain [127.0.0.1]) by ton.toronto.redhat.com (8.13.1/8.13.1) with ESMTP id n1P2rf8R020943; Tue, 24 Feb 2009 21:53:41 -0500 Received: (from fche@localhost) by ton.toronto.redhat.com (8.13.1/8.13.1/Submit) id n1P2rfTJ020942; Tue, 24 Feb 2009 21:53:41 -0500 To: Josh Stone Cc: Daniel Tralamazza , systemtap@sourceware.org Subject: Re: PThread profiling References: <49A3046E.3050403@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 25 Feb 2009 07:22:00 -0000 In-Reply-To: <49A3046E.3050403@redhat.com> (Josh Stone's message of "Mon, 23 Feb 2009 12:17:50 -0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2009-q1/txt/msg00519.txt.bz2 Josh Stone writes: >> It worked fine, but the overhead was causing measurements errors >> (too slow == higher contention probability). It was clear that I >> had to use static markers, all I had to do was patch glibc/nptl >> and voila. > > Can you share performance numbers on this? I'd like to see the > comparison of unprobed, function uprobes, and static markers... Since user-space static markers are currently implemented in terms of uprobes, it should not assist performance. We may devise a different method to jump to the kernel-side handler (e.g., some creatively misused system call/signal that we can catch via utrace/kprobes), at which point it could get much faster. - FChE