Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753730AbdIGAWt (ORCPT ); Wed, 6 Sep 2017 20:22:49 -0400 Received: from mail-qt0-f171.google.com ([209.85.216.171]:34653 "EHLO mail-qt0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752855AbdIGAWs (ORCPT ); Wed, 6 Sep 2017 20:22:48 -0400 X-Google-Smtp-Source: AOwi7QBcBv4jOaasfCvnxTVPhbrG/195ZwRuiQUz0YZtLpwJ0mMckatXM2+5oPE/lnW/i7uuV0dVuQP8lDd/qxRIsyc= MIME-Version: 1.0 In-Reply-To: <20170906084040.uhqibgnls36rdh2a@hirez.programming.kicks-ass.net> References: <20170903085051.6348-1-joelaf@google.com> <20170903085051.6348-3-joelaf@google.com> <20170904075614.bjkkrgyv2dpz7x5v@hirez.programming.kicks-ass.net> <20170904194426.GD17526@worktop.programming.kicks-ass.net> <20170904193436.4a37fae4@gandalf.local.home> <20170905065230.lq5fsxgiv6ynehxp@hirez.programming.kicks-ass.net> <20170906084040.uhqibgnls36rdh2a@hirez.programming.kicks-ass.net> From: Joel Fernandes Date: Wed, 6 Sep 2017 17:22:46 -0700 Message-ID: Subject: Re: [PATCH 2/2] tracing: Add support for critical section events To: Peter Zijlstra Cc: Steven Rostedt , LKML , kernel-team@android.com, Ingo Molnar , Byungchul Park , Tejun Heo Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1927 Lines: 50 Hi Peter, On Wed, Sep 6, 2017 at 1:40 AM, Peter Zijlstra wrote: > On Tue, Sep 05, 2017 at 09:35:11AM -0700, Joel Fernandes wrote: >> On Mon, Sep 4, 2017 at 11:52 PM, Peter Zijlstra wrote: >> > On Mon, Sep 04, 2017 at 08:26:13PM -0700, Joel Fernandes wrote: >> > >> >> Apologies, I meant (without the "off"): >> >> >> >> subsystem: atomic_section >> >> events: >> >> irqs_disable >> >> irqs_enable >> >> preempt_disable >> >> preempt_enable >> >> >> >> and additionally (similar to what my patch does): >> >> preemptirq_enable >> >> preemptirq_disable >> >> >> > >> > What do you need the last for? >> >> The last 2 events above behave as 'disable' means either preempt or >> irq got disabled, and 'enable' means *both* preempt and irq are >> enabled (after either one of them was disabled). >> >> This has the advantage of not generating events when we're already in >> an atomic section when using these events, for example acquiring spin >> locks in an interrupt handler might increase the preempt count and >> generate 'preempt_disable' events, but not preemptirq_disable events. >> This has the effect of reducing the spam in the traces when all we >> care about is being in an atomic section or not. These events happen a >> lot so to conserve space in the trace buffer, the user may want to >> just enable the latter 2 events. Does that sound Ok to you? > > Hurm,... how about placing a filter on the other 4, such that we only > emit the event on 0<->x state transitions? IIRC tracing already has > filter bits and eBPF bits on that allow something like that. > > That avoids having to introduce more tracepoints and gets you the same > results. Sure, that sounds fine to me. I dropped the last 2 events from a repost of the series since we can add that in (combined preempt and irq) at a later time using similar methods as you're suggesting. thanks, -Joel