From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71885 invoked by alias); 29 Nov 2016 19:21:11 -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 71871 invoked by uid 89); 29 Nov 2016 19:21:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*jistone, H*i:sk:rjxYHYm, H*f:sk:SL1Lg@m, H*M:e9ee X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Nov 2016 19:21:01 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F3333C0567B2; Tue, 29 Nov 2016 19:20:59 +0000 (UTC) Received: from [10.3.116.156] (ovpn-116-156.phx2.redhat.com [10.3.116.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uATJKxSk016679; Tue, 29 Nov 2016 14:20:59 -0500 Subject: Re: kernel function probe overhead To: Aubrey Li , "Frank Ch. Eigler" References: Cc: systemtap@sourceware.org From: Josh Stone Message-ID: <9f297ed9-e535-5f4d-e9ee-98507961f3f6@redhat.com> Date: Tue, 29 Nov 2016 19:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-q4/txt/msg00099.txt.bz2 On 11/28/2016 07:30 PM, Aubrey Li wrote: >> Another solution would be to have per-thread global variables. Since >> > the kernel doesn't help us out with this, we'd have to emulate it >> > somehow, and for this to be wortwhile, it'd have to work faster than >> > ordinary locked/shared array[tid()] accesses. >> > > Is this a suggestion for me? How to do this? There are relevant RFEs for stap already: per-cpu: https://sourceware.org/bugzilla/show_bug.cgi?id=10795 per-thread: https://sourceware.org/bugzilla/show_bug.cgi?id=10796 The latter was closed on the hunch that it wouldn't help much, but that could still be explored if someone is interested.