Received: by 10.192.165.148 with SMTP id m20csp52415imm; Tue, 1 May 2018 17:14:03 -0700 (PDT) X-Google-Smtp-Source: AB8JxZob3VlX8V2qjBLR+6kX46MeCk354lJ+AH/lA6Sn2Hx5P61+X7eE+/ytKcpK6oz/AD/yxWtI X-Received: by 10.98.231.16 with SMTP id s16mr17422486pfh.227.1525220043177; Tue, 01 May 2018 17:14:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525220043; cv=none; d=google.com; s=arc-20160816; b=HhtlPgqzRsvRIFGz/7Cga5IoYo4Vh1bvKC6Yx5UQZBJWq6AH665omHjm2nTRoKZipc wDqfM2Jj9oQrq+6/YSsOg//u2pijUr8pRsQDTx1ELwZw1a9QVBWfvzeL8OlbwROD1N6u dT9Um3glr9fLzb0SDCWhqSfD01VGhDtjHlcPuhZ2wjAXRz+G8uO+4oCUU2jyeqStw8M2 NZQQ4dg6ODDXoOjbNoEIGwe3Dnua7vKVWKyO5RFhoSXGQbe0ldBuPIItUx00o2VE8vjt r6wr/aVTQWaZ7eq0XF/IFcNHJ77K5ER7p6MIDO8T5WjgK6qstoMwmdWm37CKR5ry8LbY /Rmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:dkim-signature:arc-authentication-results; bh=gQt9KMJslCv9E9Jq8wEtHvvPFIaOREc/Vkw5e123Bkk=; b=CBx6pQhJVU79pus1S2n2+hlN74J8DIMrdQJeXOghHUxXFxF06KFPdze3t5mdUwGptM TTZjVknOqCxAOvCxygG4Lw8Rv140qZ1NiY9gflfsnfLWN49KJu6Y6jSA8VhmBNU6IxEJ Wohd4W70cyc5aMARHH8pbOzGAU1zLWgYprUEb6zOuPd9aRSzoukpyJIQFrDZJPjcAlSP EcSK1MZQprujEwVvr26c3UX+egdiyIw5rifsGAG0PyUkblxqu8UskJ4AL5e/vCF3Ahg/ iAMkAi3X9tisePLxd6oxIjFt3SGm8zwmaF0fsVTBq3xgddGaYMTgrKMi6G3qbwibygwZ EsEA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=i4kIyPKU; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1-v6si2083649plk.521.2018.05.01.17.13.48; Tue, 01 May 2018 17:14:03 -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=@gmail.com header.s=20161025 header.b=i4kIyPKU; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753350AbeEBAMb (ORCPT + 99 others); Tue, 1 May 2018 20:12:31 -0400 Received: from mail-pg0-f45.google.com ([74.125.83.45]:47096 "EHLO mail-pg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751825AbeEBAM2 (ORCPT ); Tue, 1 May 2018 20:12:28 -0400 Received: by mail-pg0-f45.google.com with SMTP id z4-v6so9292537pgu.13 for ; Tue, 01 May 2018 17:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=gQt9KMJslCv9E9Jq8wEtHvvPFIaOREc/Vkw5e123Bkk=; b=i4kIyPKUCQ630uh9xNCs8NLXMalWmepBQSzA9Tnjwbd0YV+H7aYxPw56LP+c/NFkpy fjMxdpkXsmxHjYB852hrqneX2esMxGm98/1Prn4oJGNB9Iw1tIr/AStyDe6T2VNg9hUY sb1QpFANtQIwytibKA4rC+TCZGHykjnZufLbQ/j2MAM9Kw+gU2YWGABXid9uwB7Q0sjg X2Ai31zNItkDziGz5lg8y0A70yqkWRq06RYqyGoWUEDlLHqgPt/X3KitKcQzBm9L9+6M MJnP50tFIZnrWSivtE3YgCi7OLd9jFj/qbjqa88zTNAGCOKPDVbXe5PCrLP/eqIxTdz0 tLNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=gQt9KMJslCv9E9Jq8wEtHvvPFIaOREc/Vkw5e123Bkk=; b=JASxsCPlOVw6/hoOWYBA8Cuja4LhE8hBqKQ/LitqX043MtUu7A4wHywEfRglSaRLvT BlVmVtkaVggOFlrq9eldadI4luXTpEQ9U3ioM+27v9ziUWUn5rBnOsadiH8kLZjq112e avCoGhfUQwj9hR8EqlqFSsrYueKmcxWgMH+3av6ji+/X5nJBy0GjMOqDZHkCJweFBC+m 1MI72QZ2MhNKk3SI8qn1ZEMtP0lVaKBVBHO2H66Il20krEiZzxGzN4nVQZj93xtTu9oR Rq8jqGp7M8JyiAe823n/vhvR0r7fvMtkr70edH6BSZ1EZsZ3/ZYMQqdHtUEA9qzTpLWx bEUw== X-Gm-Message-State: ALQs6tCebYea1o+nE51CjGLRgc7Tp5npFoxKumygiQvlhsxNkr0Ye6De wyDJI9ntqxKSuicbwv/2eQo= X-Received: by 2002:a65:4b02:: with SMTP id r2-v6mr14282198pgq.82.1525219948091; Tue, 01 May 2018 17:12:28 -0700 (PDT) Received: from roar.ozlabs.ibm.com (59-102-70-78.tpgi.com.au. [59.102.70.78]) by smtp.gmail.com with ESMTPSA id l90sm21610520pfb.149.2018.05.01.17.12.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 May 2018 17:12:27 -0700 (PDT) Date: Wed, 2 May 2018 10:12:14 +1000 From: Nicholas Piggin To: Joel Fernandes Cc: Steven Rostedt , Peter Zijlstra , Ingo Molnar , Linux Kernel Mailing List Subject: Re: [PATCH] tracing/irqtrace: only call trace_hardirqs_on/off when state changes Message-ID: <20180502101214.746650bc@roar.ozlabs.ibm.com> In-Reply-To: References: <20171116161506.19691-1-npiggin@gmail.com> <20180501144620.1e832a09@gandalf.local.home> <20180501191951.GJ12217@hirez.programming.kicks-ass.net> <20180501153840.7281022a@gandalf.local.home> <20180501194838.GK12217@hirez.programming.kicks-ass.net> <20180501160059.6df6aae4@gandalf.local.home> Organization: IBM X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 1 May 2018 14:15:14 -0700 Joel Fernandes wrote: > On Tue, May 1, 2018 at 1:00 PM, Steven Rostedt wrote: > > On Tue, 1 May 2018 21:48:38 +0200 > > Peter Zijlstra wrote: > > > >> On Tue, May 01, 2018 at 03:38:40PM -0400, Steven Rostedt wrote: > >> > On Tue, 1 May 2018 21:19:51 +0200 > >> > Peter Zijlstra wrote: > >> > >> > > Now, lockdep only minimally tracks these otherwise redundant operations; > >> > > see redundant_hardirqs_{on,off} counters, and loosing that doesn't seen > >> > > like a big issue. > >> > > > >> > > But I'm confused how this helps track superfluous things, it looks like > >> > > it explicitly tracks _less_ superfluous transitions. > >> > > >> > I think it is about triggering on OFF->OFF a warning, as that would > >> > only happen if we have: > >> > > >> > local_irq_save(flags); > >> > [..] > >> > local_irq_disable(); > >> > > >> > >> Ahh, ok. Yes, that is easier to do with these changes. The alternative > >> is to add more information to the tracehooks such that we can do the > >> same internally, but whatever. > >> > >> Yeah, I'm fine with the proposed change, but maybe improve the Changelog > >> a little for slow people like me :-) > > > > Great! > > > > Nicholas, > > > > I know this is an old patch (from last November), but want to send it > > again with a proper change log and signed off by? > > I actually wrote the exact same patch yesterday with changes Matsami > suggested. However I decided not to send it, since it didn't have any > performance improvement (which was the reason I wrote it). > > Also with my recent set, I don't think it will help detect repeated > calls to trace_hardirqs_off because we are handling that recursive > case by using per-cpu variable and bailing out if there is a > recursion, before even calling into lockdep. > > I have mixed feelings about this patch, I am Ok with this patch but I > suggest its sent with the follow-up patch that shows its use of this. > And also appreciate if such a follow-up patch is rebased onto the IRQ > tracepoint work: https://patchwork.kernel.org/patch/10373129/ > > What do you think? I'll try to dig it up and resend. Thanks for the feedback on it. Thanks, Nick