From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754364AbcKUShE (ORCPT ); Mon, 21 Nov 2016 13:37:04 -0500 Received: from one.firstfloor.org ([193.170.194.197]:51802 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752810AbcKUShC (ORCPT ); Mon, 21 Nov 2016 13:37:02 -0500 Date: Mon, 21 Nov 2016 10:37:00 -0800 From: Andi Kleen To: Steven Rostedt Cc: Andi Kleen , Peter Zijlstra , Jiri Olsa , "Paul E. McKenney" , linux-kernel@vger.kernel.org, Ingo Molnar , Josh Triplett , Jan Stancek Subject: Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage! Message-ID: <20161121183700.GW26852@two.firstfloor.org> References: <20161121005343.GB1891@krava> <20161121092850.GF3102@twins.programming.kicks-ass.net> <20161121170612.GT26852@two.firstfloor.org> <20161121171853.GK3092@twins.programming.kicks-ass.net> <20161121174504.GU26852@two.firstfloor.org> <20161121130115.2f0f38e7@gandalf.local.home> <20161121180654.GV26852@two.firstfloor.org> <20161121132220.17fb0515@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161121132220.17fb0515@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > It tries to be optimized. I "unoptimized" it a while back to pull out > all the inlines that were done in the tracepoint itself. That is, the > trace_() function is inlined in the code itself. By > breaking that up a bit, I was able to save a bunch of text because the > tracepoints were bloating the kernel tremendously. Just adding a few inlines won't fix the gigantic bloat that is currently there. See the PT trace I posted earlier (it was even truncated, it's actually worse). Just a single enabled trace point took about a us. POPF can cause some serializion but it won't be more than a few tens of cycles, which would be a few percent at best. Here is it again untruncated: http://halobates.de/tracepoint-trace $ wc -l tracepoint-trace 640 tracepoint-trace $ head -1 tracepoint-trace [001] 264171.903577780: ffffffff810d6040 trace_event_raw_event_sched_switch push %rbp $ tail -1 tracepoint-trace [001] 264171.903578780: ffffffff810d6117 trace_event_raw_event_sched_switch ret > There can be more optimization done too. But just because it's not > optimized to the best it can be (which should be our goal) is not > excuse to bloat it more with popf! Ok so how should tracing in idle code work then in your opinion? -Andi