From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48349 invoked by alias); 11 May 2018 19:25:57 -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 48306 invoked by uid 89); 11 May 2018 19:25:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=opted, Hx-languages-length:1940, claims X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 May 2018 19:25:55 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 160AE8185344 for ; Fri, 11 May 2018 19:25:54 +0000 (UTC) Received: from segfault.boston.devel.redhat.com (segfault.boston.devel.redhat.com [10.19.60.26]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0819C112D186; Fri, 11 May 2018 19:25:54 +0000 (UTC) Received: by segfault.boston.devel.redhat.com (Postfix, from userid 3734) id B0877B97CD; Fri, 11 May 2018 15:25:53 -0400 (EDT) From: Jeff Moyer To: systemtap@sourceware.org Cc: Jeff Moyer Subject: [PATCH 1/3] io_submit.stp: fix array membership test Date: Fri, 11 May 2018 19:25:00 -0000 Message-Id: <20180511192552.12849-2-jmoyer@redhat.com> In-Reply-To: <20180511192552.12849-1-jmoyer@redhat.com> References: <20180511192552.12849-1-jmoyer@redhat.com> X-SW-Source: 2018-q2/txt/msg00060.txt.bz2 io_submit.stp keeps track of threads which are currently executing in the io_submit system call like so: probe syscall.io_submit { in_iosubmit[tid()] = 1 } probe syscall.io_submit.return { /* this assumes a given proc will do lots of io_submit calls, and * so doesn't do the more expensive "delete in_iosubmit[p]". If * there are lots of procs doing small number of io_submit calls, * the hash may grow pretty big, so using delete may be better */ in_iosubmit[tid()] = 0 } However, the test to see if a thread is currently executing in io_submit is performed using the membership operator 'in': if (tid() in in_iosubmit) This is obviously wrong. We can do one of two things: 1) change the test to if (in_iosubmit[tid()] == 1) or 2) just perform the delete in the return probe While I agree that we typically have a small number of threads performing io_submit, I don't believe there is substance to the performance claims for the delete operator. So, I've opted for solution 2. Signed-off-by: Jeff Moyer --- testsuite/systemtap.examples/io/io_submit.stp | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/testsuite/systemtap.examples/io/io_submit.stp b/testsuite/systemtap.examples/io/io_submit.stp index 74ab639..c5edd66 100755 --- a/testsuite/systemtap.examples/io/io_submit.stp +++ b/testsuite/systemtap.examples/io/io_submit.stp @@ -28,12 +28,7 @@ probe syscall.io_submit { * when we return from sys_io_submit, record that we're no longer there */ probe syscall.io_submit.return { - /* this assumes a given proc will do lots of io_submit calls, and - * so doesn't do the more expensive "delete in_iosubmit[p]". If - * there are lots of procs doing small number of io_submit calls, - * the hash may grow pretty big, so using delete may be better - */ - in_iosubmit[tid()] = 0 + delete in_iosubmit[tid()] } /* -- 2.8.2.335.g4bb51ae