Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752076AbdIFIlC (ORCPT ); Wed, 6 Sep 2017 04:41:02 -0400 Received: from merlin.infradead.org ([205.233.59.134]:32780 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750832AbdIFIk4 (ORCPT ); Wed, 6 Sep 2017 04:40:56 -0400 Date: Wed, 6 Sep 2017 10:40:40 +0200 From: Peter Zijlstra To: Joel Fernandes Cc: Steven Rostedt , LKML , kernel-team@android.com, Ingo Molnar , Byungchul Park , Tejun Heo Subject: Re: [PATCH 2/2] tracing: Add support for critical section events Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1581 Lines: 39 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.