From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joel Fernandes Subject: Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can Date: Tue, 01 May 2018 01:18:09 +0000 Message-ID: References: <20180417040748.212236-1-joelaf@google.com> <20180417040748.212236-4-joelaf@google.com> <20180418180250.7b6038dddba46b37c94b796c@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: LKML , linux-rt-users , Steven Rostedt , Peter Zijlstra , Ingo Molnar , Mathieu Desnoyers , Tom Zanussi , Namhyung Kim , Thomas Gleixner , Boqun Feng , Paul McKenney , "Cc: Frederic Weisbecker" , Randy Dunlap , Fenguang Wu , Baohong Liu , Vedang Patel To: Masami Hiramatsu Return-path: In-Reply-To: <20180418180250.7b6038dddba46b37c94b796c@kernel.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-rt-users.vger.kernel.org On Wed, Apr 18, 2018 at 2:02 AM Masami Hiramatsu wrote: > On Mon, 16 Apr 2018 21:07:47 -0700 > Joel Fernandes wrote: > > With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need > > to if local_irq_restore or local_irq_save didn't actually do anything. > > > > This gives around a 4% improvement in performance when doing the > > following command: "time find / > /dev/null" > > > > Also its best to avoid these calls where possible, since in this series, > > the RCU code in tracepoint.h seems to be call these quite a bit and I'd > > like to keep this overhead low. > Can we assume that the "flags" has only 1 bit irq-disable flag? > Since it skips calling raw_local_irq_restore(flags); too, > if there is any state in the flags on any arch, it may change the > result. In that case, we can do it as below (just skipping trace_hardirqs_*) > int disabled = irqs_disabled(); > if (!raw_irqs_disabled_flags(flags) && disabled) > trace_hardirqs_on(); > raw_local_irq_restore(flags); > if (raw_irqs_disabled_flags(flags) && !disabled) > trace_hardirqs_off(); With changes to the tracepoint implementation which uses srcu instead of rcu, I'm not able to see a performance improvement with the above patch. For this reason, I will drop this patch from next series. thanks, - Joel