Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp984016imm; Fri, 15 Jun 2018 09:17:08 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLg3RzWGBAojDiTfmnXaW2LkycpVoivb/8R558Ya71i7/XLZXR1E7Jpy0tGAkRJ1z2SfW+u X-Received: by 2002:a63:6642:: with SMTP id a63-v6mr2161421pgc.408.1529079428199; Fri, 15 Jun 2018 09:17:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529079428; cv=none; d=google.com; s=arc-20160816; b=egtsMDTHggZhR4egsvmPr/hjzmR4uxibKjDZYFTwk5L7tgdOynP/sn96zsLKXl2HvE dzOaV4l9qa7Mt3nl3Am5ph0QMpW7QtZPkKbjmggnHwySArNi+UFM41pFx1nQ71KyMAPj T+5BCh5klWQJCYfc124DeR7zLWqwy7U+pQn5eH2PUtzsJ6YQihDZ4IOP3jBgw+/rXEu/ Rnb41czw5vD/BN9HIIbrACwjcC5U4hMF9hCzxAZfe3dHCcERKLDDWMIctpyT4eehKcPd txV+JXbL/l8I1DOnutqsfb/eG4TokgpqI3qcMA56Cd+4a+fpi0D1IXISR9qZ09o+s389 wQww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=dzkRX7SEPUISXC/sZdhruzXqYyTXvVPIpE5Hn0L4pBU=; b=SVTMSX6klsfausLDj9aKzaVyqK16ScwWjjeG11hGRoW1Pzbqf9mINFqXA7e44xsPjB 9UX7WXelSCFRTsQqIXuf+PsYJz9LAQcw5RSqhSbL/aebHHrIMayEVSPodY7qCPXhSEYN poobGYMF69h8jZ5PXr7rwYLnSH0w9PGzQDhKLHq5sEzV5lb7xf4GI8IkfZb19jcsI3Nw 6bDaDjjrgTUWAqVa72Mb++P/bzROdffSqUaePyZtqERWdARqDGUhuxY+FZFKvw82BdlH ZVOG0PVEmnPYH8+s+4dYfwm7zmi+W1F+gAqXi7mGUtxY7lUuI3TqccHrNYJeAd2ch615 JBXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x135-v6si6916691pgx.424.2018.06.15.09.16.52; Fri, 15 Jun 2018 09:17:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966025AbeFOQQH (ORCPT + 99 others); Fri, 15 Jun 2018 12:16:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:60062 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964966AbeFOQQG (ORCPT ); Fri, 15 Jun 2018 12:16:06 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6FD71208AF; Fri, 15 Jun 2018 16:16:05 +0000 (UTC) Date: Fri, 15 Jun 2018 12:16:03 -0400 From: Steven Rostedt To: Joel Fernandes Cc: "BarclaycardUS" <1eaff0972layfivcia3p5kbiaaaaabtyzcthzutkdtiyaaaaa@offers.BarclaycardUS.com>, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] tracing: Call triggers only if event passes filter checks Message-ID: <20180615121603.33007151@gandalf.local.home> In-Reply-To: <20180615010113.127718-1-joel@joelfernandes.org> References: <20180615010113.127718-1-joel@joelfernandes.org> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Jun 2018 18:01:13 -0700 Joel Fernandes wrote: > From: "Joel Fernandes (Google)" > > Currently, trace event triggers are called regardless of if the event > filter checks pass or fail. Thus if one were to enable event triggers > and filters at the same time, then the triggers will always be called > even if the filter checks didn't pass. > > This is a problem for a usecase I was experimenting with: measuring the > time preemption is disabled using synthetic events and dump the stack > using the stacktrace trigger if the total preempt off time was greater > than a threshold. Following are the commands for the same: > > Create synthetic event: > > echo 'preemptdisable u64 lat' >> \ > /sys/kernel/debug/tracing/synthetic_events > > echo 'hist:keys=cpu:ts0=common_timestamp.usecs:scpu=cpu' >> \ > /sys/kernel/debug/tracing/events/preemptirq/preempt_disable/trigger > > echo 'hist:keys=cpu:wakeup_lat=common_timestamp.usecs-$ts0:\ > onmatch(preemptirq.preempt_disable).preemptdisable($wakeup_lat)' >> \ > /sys/kernel/debug/tracing/events/preemptirq/preempt_enable/trigger > > Enable synthetic event: > > echo stacktrace > /sys/kernel/debug/tracing/events/synthetic/preemptdisable/trigger > echo 'lat > 400' > /sys/kernel/debug/tracing/events/synthetic/preemptdisable/filter > echo 1 > /sys/kernel/debug/tracing/events/synthetic/preemptdisable/enable > > With the patch, the stacktrace is triggered only if the filter checks > passed. It also seems sensible to call triggers only if filter checks > pass so lets do that. No, it worked as expected. The filter is only to be used it the event should be recorded or not. What you wanted to do is: echo 'stacktrace if lat > 400' > events/synthetic/preemptdisable/trigger -- Steve