From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 925CD3850433 for ; Tue, 18 Aug 2020 19:11:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 925CD3850433 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-558-iErKtTDlOTS5nMrqyBs18A-1; Tue, 18 Aug 2020 15:11:20 -0400 X-MC-Unique: iErKtTDlOTS5nMrqyBs18A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 500F581F02D; Tue, 18 Aug 2020 19:11:19 +0000 (UTC) Received: from redhat.com (ovpn-112-64.phx2.redhat.com [10.3.112.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2B93416597; Tue, 18 Aug 2020 19:11:19 +0000 (UTC) Received: from [127.0.0.1] (helo=vm-rhel7) by redhat.com with esmtp (Exim 4.94) (envelope-from ) id 1k870v-00088X-GZ; Tue, 18 Aug 2020 15:11:17 -0400 From: fche@redhat.com (Frank Ch. Eigler) To: Kun , "Arkady" , craig@2ndquadrant.com Subject: Re: Fwd: systemtap global var lead to high cpu References: cc: systemtap@sourceware.org Reply-To: systemtap@sourceware.org Date: Tue, 18 Aug 2020 15:11:16 -0400 In-Reply-To: (Kun via Systemtap's message of "Sat, 25 Jul 2020 10:45:02 +0800") Message-ID: <871rk3wyzv.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:11:25 -0000 Hi - Improvements made for PR26296 should dramatically improve your global variable locking issues with systemtap. Please let us know if it's enough! https://sourceware.org/git/?p=systemtap.git;a=commit;h=25012d82e181afe7de5cb8bcc2cefcef0b123e32 - FChE ------------------------------------------------------------------------ PR26296: lock pushdown optimization Implements an algorithm to push lock/unlock operations downward in the syntax tree, to just enclose the smallest possible region that deals with global variables. This means two common patterns run with much more concurrency than before: global a probe foo { if (condition) { a++ } else { something_else() } } will only lock globals -if- the condition is true, so something_else() would run unlocked. Also: global a probe foo { if (a) { long_twisty_operation(); } } will unlock globals right after the condition is evaluated, so long_twisty runs unlocked. Previous behaviour is avilable with --compatible=4.3. New test case lock-pushdown.stp asserts locking conditions throughout various relevant constructs.