Received: by 10.192.165.148 with SMTP id m20csp373759imm; Fri, 20 Apr 2018 00:08:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/79WiVH3PYg6dJ+YGn2hMU/Rd9OclcdCt7X0X+cUVwdejDID3spDBkOz2XsqdoPJSUmQ3s X-Received: by 10.99.165.3 with SMTP id n3mr7486955pgf.19.1524208127549; Fri, 20 Apr 2018 00:08:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524208127; cv=none; d=google.com; s=arc-20160816; b=Zojj6UvFu+JfZrp/bRTV07NyX1064vouOScNO3Xwdu5/BEikARh1Jd/raiWTCDiai0 aWPTa2234pQnHVIIh0pn6Lf4ApTLPND17rWxd6JgnKmlthdKxw0n5GpmI0YLFOhkwMqZ FUFtz+IVEdeD4PyrhH20JJEY+9E+WuLc6bt4GkD68HBxk7PDMUVamgxDJkB5bace7KW+ vNqQRPvNe0icj9zVfAedBkq4CZWOrU6r4WUsxTMSXT6ro72wdPQI+XgadU7Lfv5OUrS2 kDgCiNDjbz5YGt9smTg/+3QPJsDXGnu5+9IRDsQvFEJv4H3gwY3d4LIJtxCkqsM96V83 zi4Q== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=wLEhuZDWTEU8SDsC2sM1BhbBP0/zpxqwgXkCp1GQT6g=; b=Kz+hKjMO9d4jaDemsSG/wYzQQz1uNC4JAzZbPvWHPazxpOJKf5Xp4uUn5bcQ32FcPV bUcDfh+ixlkOxIdDQNYZ08qkZw0wvJNvlgdAUyTHE5++/vap8R1yTIgi9qMZ4X+J81l/ flPvmcd6DWou61NMyjqtWp67yuQtx6TPMs5vxqzgI4mBPDFfrPohQ3qPwLIuxEMMfz3o 8JoYryXCL8OfvIt09vdbvRhL/nfmNDsBCIQtZ1gmBPCOCuyMiNkpU2mBnaVUZQB7ib/w /yoTDzQMG4qh9RU6v7XWfQvgBuRd1mmh7r+GCyph+DVKCNLz7MX2lWcfwaL5f32hCqiD Yq1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=hKpj1fQr; 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 r5-v6si5175425plo.414.2018.04.20.00.08.31; Fri, 20 Apr 2018 00:08:47 -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=hKpj1fQr; 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 S1753895AbeDTHHX (ORCPT + 99 others); Fri, 20 Apr 2018 03:07:23 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:33036 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753765AbeDTHHU (ORCPT ); Fri, 20 Apr 2018 03:07:20 -0400 Received: by mail-it0-f41.google.com with SMTP id x144-v6so2216344itc.0 for ; Fri, 20 Apr 2018 00:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wLEhuZDWTEU8SDsC2sM1BhbBP0/zpxqwgXkCp1GQT6g=; b=hKpj1fQrazPUm8dnu92bPWITenAGlogZphUSaCXslv8hJ/cmRCjejjZNJ8CKM0vCEY vQEjjKlSgUnxAk0S9GrzaUBSiebPuvcoOmeWxAutlHhQ09CZQtMTQw9ieehzgMIlsyZD RwQFluVjI8gGfUYhPM3XLY0oJuT8GAhff6R11SLgpOc0tGTYuLXOFuN+1D3JTWH7MeDP nqc1HKN/R59S9KnwYfRL9QVWEa74BoMPdvOEBDo5Lks8FwKi9XU7UYx7AhlYQBjqDaOw L9gytY0YU8/TexkMdXUx0gXXOqASHzUd23Wtfiz33Muz2ncqSAhmfU2sXBwa9lGALVLw gX/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wLEhuZDWTEU8SDsC2sM1BhbBP0/zpxqwgXkCp1GQT6g=; b=bKn/k5VFvqq/sigl31AtQCj8r0YqZaDAgtXvpXozvaV6AARNgwgIivcyZ7eAxRsxT8 pyifAOqRcYUHM7Hu1Dw6qFBqN2G5PEjtER0jpmbTTDukVqQ6oM20hmfSlg+o+LDN5TWe oDIKT3YGTKrPyYxs8GhxC+8IvH/+cX7fTylYKKHkxZ4FwCRkQBO+N5rknTlKuWhZP7uF d7amBNCs+hIuZ/UqpAs9NklrDRPIX2CzsYTMxLbGpScmp7xuWjdlq+aN/q9lCXHLnW+v 8sgG8zVgfL5OqmoKbEc5HJi5NedMWps2zfW4x45Hn+MbtU/F7X6+ljeiOU17GJNQTcrL WEjg== X-Gm-Message-State: ALQs6tCBf2F3/1lHNAEE+76c2q6v0Ekvrgmjfh1En8D0KproXkTXGE/X SmR2ZHKw73vJ7IVW1YLxoSSw73rVhG/tbog+TVF7Fg== X-Received: by 2002:a24:de44:: with SMTP id d65-v6mr1930830itg.41.1524208039322; Fri, 20 Apr 2018 00:07:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.181.213 with HTTP; Fri, 20 Apr 2018 00:07:18 -0700 (PDT) In-Reply-To: <20180419054302.GD13370@sejong> References: <20180417040748.212236-1-joelaf@google.com> <20180417040748.212236-4-joelaf@google.com> <20180418180250.7b6038dddba46b37c94b796c@kernel.org> <20180419054302.GD13370@sejong> From: Joel Fernandes Date: Fri, 20 Apr 2018 00:07:18 -0700 Message-ID: Subject: Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can To: Namhyung Kim Cc: Masami Hiramatsu , LKML , linux-rt-users@vger.kernel.org, Steven Rostedt , Peter Zilstra , Ingo Molnar , Mathieu Desnoyers , Tom Zanussi , Thomas Glexiner , Boqun Feng , Paul McKenney , Frederic Weisbecker , Randy Dunlap , Fenguang Wu , Baohong Liu , Vedang Patel , kernel-team@lge.com 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 Hi, Thanks Matsami and Namhyung for the suggestions! On Wed, Apr 18, 2018 at 10:43 PM, Namhyung Kim wrote: > On Wed, Apr 18, 2018 at 06:02:50PM +0900, 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, > > I don't know how many it impacts on performance but maybe we can have > an arch-specific config option something like below? The flags restoration I am hoping is "cheap" but I haven't measured specifically the cost of this though. > > >> 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 (disabled == raw_irqs_disabled_flags(flags)) { > #ifndef CONFIG_ARCH_CAN_SKIP_NESTED_IRQ_RESTORE > raw_local_irq_restore(flags); > #endif > return; > } Hmm, somehow I feel this part should be written generically enough that it applies to all architectures (as a first step). > >> >> 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(); I like this idea since its a good thing to do the flag restoration just to be safe and preserve the current behaviors. Also my goal was to reduce the trace_ calls in this series, so its probably better I just do as you're suggesting. I will do some experiments and make the changes for the next series. thanks, - Joel