Received: by 10.192.165.148 with SMTP id m20csp4402024imm; Mon, 30 Apr 2018 18:21:00 -0700 (PDT) X-Google-Smtp-Source: AB8JxZppqaMRVFr9sZcz+xC6B3nGTDC6BQjLdIe7lGx9ZgIo8vHhAyfEyY8/kxXganwy3/kyDIgr X-Received: by 10.98.224.76 with SMTP id f73mr13945241pfh.88.1525137660495; Mon, 30 Apr 2018 18:21:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525137660; cv=none; d=google.com; s=arc-20160816; b=HonGVEPIEB8B5mTiu9aVhEycU9WOH3psOF7sMPz0XW+71RMSiaWP477khMWKayDP6U zad922Nxw8lf2oUc7u/wwrEjQr9CT3tvPNczEll6FKayzxFbyErVnHZ3D1/xd3xrb/R0 Ja5o4lc6rwEVVgKpZyZR6pjR2rBBNVOmY3/jF8csbjExGK5cmuzPak8+wi0aZAmL2r95 rVx5UH6e/bsmnmc+x/8R9fv1PJgzHGzaMlcQh06lzF9KRGcSzWg4e4eiRTvuoc7ZRA62 Oaa4xbtUrp+eIbZemLAiHt90JaHTvsR3MtDZpqIA78yE/92BJ6gwMcdUG2ETcuBDWVpx AoEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=XGXkfEVSvC/3kxoyw8aPMw9Nq0rvu+OYwy8rw/L92vY=; b=jORwfzOi5ry6MvZnSFwK7F19RAoSnk8rsdU7sj8W0VjSrbgilOblXH1EMfHDUPSIwm eIPfutKt5fxXmCdUaNZi5t0ViEaO/bfJp36DuH/h3XQfTBgAsSGr6zsKe2aAVQsTXWbB 0v7xWdXu3ZSV2ovmkSUelvnrk+k9J5XZmyRJx9O4srZ+xhmr0Dl8hD7gR73UZbaQsaBa XWY6X1e4NlWduI0QpeIK+3GIiByOEMFrVt9aArIDoWpgwvdu+wvOli88yAwjvtjY7RQ8 MWdoi5gzj/0LPIuubfvFfa7WO5uSO5W8HlBTm52tOnlJ/vz3AkBsSpUHgUJLkp762rax rYHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=D+3C6wIf; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a69-v6si8503998pli.391.2018.04.30.18.20.31; Mon, 30 Apr 2018 18:21:00 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=D+3C6wIf; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752667AbeEABSX (ORCPT + 99 others); Mon, 30 Apr 2018 21:18:23 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:54126 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbeEABSV (ORCPT ); Mon, 30 Apr 2018 21:18:21 -0400 Received: by mail-it0-f46.google.com with SMTP id f65-v6so8124148itd.3 for ; Mon, 30 Apr 2018 18:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XGXkfEVSvC/3kxoyw8aPMw9Nq0rvu+OYwy8rw/L92vY=; b=D+3C6wIfzyz9t5lijjJj8Es7udqzQyRFZrUC6HvyqS80uuD4+78ZfrOR87U/1AoDcy zgniIvgnT1M2+PsB0EbztYRXy0OIy8Q5nCkuxqS0eVJhoNg9iOuo75dcWDMM92STLFY5 yFdV/6yjQNN4RDLd25sLRzvoioCR1WIIpeeXBrNWX8q600SQHqZWIFjd1yGxNLcNxvNf Bk3Ydao6RjS2g/ZLjU6EXkBPOQ+tvNnJe1KkEKABq4TwtBKu3qCvw166SR76s7YYILEy E/2z/Sefb4Pm+G5AFs2WTW1Vzhoy3we3XjNwSrDuqkZOZUrD+HlBWaPOT1lX9eWTBkkb +I7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XGXkfEVSvC/3kxoyw8aPMw9Nq0rvu+OYwy8rw/L92vY=; b=gc/WCeHNTl8klYZgu0PohYYmhOl//dxczHNumsEiqqruauqhGhFR2pUYhHJLyIjIO+ I7IkjvAYPSiQiAbPSNsyygXOb64DsJlq74lvc7JWILDnn5FOwbqPz91rt1qx7twT7tUj ciAzuB9OCH3EABFqK2F8as2OJM++lm9E6DSodJfjdVHlH6qoOuywxtPP/kkfjYe8/TWr Ktwjwgwwh8A5x+sR7/J/wcxYEmPcr1dhXrsfh7jBchISDeo+FYte2Bd/bTqKIqTj7FNO nILl/67SVjPhkmR+Q+cJOgAY5itqLraFUiOu1L5+pdOLCUEB6Uhhjje34uf3wsNu3E+l NBhA== X-Gm-Message-State: ALQs6tCfjkXHWwZ3G6ZYVvTGFCjWpJRExS/oEvWzcur1HdYKgy8yoJqZ XBG46rEfGUHfHr4INPC9Q+V5fq9E/LD36zIqmGV1JkGw X-Received: by 2002:a24:5783:: with SMTP id u125-v6mr8930239ita.126.1525137499887; Mon, 30 Apr 2018 18:18:19 -0700 (PDT) MIME-Version: 1.0 References: <20180417040748.212236-1-joelaf@google.com> <20180417040748.212236-4-joelaf@google.com> <20180418180250.7b6038dddba46b37c94b796c@kernel.org> In-Reply-To: <20180418180250.7b6038dddba46b37c94b796c@kernel.org> From: Joel Fernandes Date: Tue, 01 May 2018 01:18:09 +0000 Message-ID: Subject: Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can To: Masami Hiramatsu 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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