From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760004Ab2HIWZo (ORCPT ); Thu, 9 Aug 2012 18:25:44 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:20184 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759854Ab2HIWZf (ORCPT ); Thu, 9 Aug 2012 18:25:35 -0400 X-Authority-Analysis: v=2.0 cv=Vb91zSV9 c=1 sm=0 a=s5Htg7xnQOKvHEu9STBOug==:17 a=OpT9cpI26MMA:10 a=3rytjJLIguwA:10 a=5SG0PmZfjMsA:10 a=Q9fys5e9bTEA:10 a=meVymXHHAAAA:8 a=ayC55rCoAAAA:8 a=qjIL11EYaxk6xwpvqt8A:9 a=PUjeQqilurYA:10 a=s5Htg7xnQOKvHEu9STBOug==:117 X-Cloudmark-Score: 0 X-Originating-IP: 72.230.195.127 Message-ID: <1344551131.6935.90.camel@gandalf.stny.rr.com> Subject: Re: [RFC][PATCH] tracepoints: Move the work out of line from hotpath sections From: Steven Rostedt To: Mathieu Desnoyers Cc: LKML , Linus Torvalds , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Masami Hiramatsu , "H. Peter Anvin" , Avi Kivity , Christoph Hellwig , Andrew Morton Date: Thu, 09 Aug 2012 18:25:31 -0400 In-Reply-To: <20120809205053.GB15109@Krystal> References: <1344544823.6935.82.camel@gandalf.stny.rr.com> <20120809205053.GB15109@Krystal> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.4.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2012-08-09 at 16:50 -0400, Mathieu Desnoyers wrote: > I guess the very first thing to do would be to benchmark this patch > thoroughly to see if it brings significant performance improvements to > the "tracing built-in, not enabled" case. If it does bring a significant > improvement, then we can consider the overhead on tracing, and see if it > makes sense to add this extra indirection on the tracing hot path. I know you and your customers focus a lot on tracing. But if there is a decent improvement with the 'off' case, then I think that's rational enough for such a change. Remember, tracing is always a second class citizen to kernel performance. But I agree that this change is probably not worth it if it's just a slight performance. > > About your "Pro" point "Less code in the hot paths", it remains to be > seen, overall, how many bytes of the removed instructions actually sit > on hot cache lines and if there is any effect on the TLB, especially > given that this "maybe-not-so-hot" code is in an unlikely branch. This is why I posted the patch now. I don't have any real good measurements for performance testing. It showed some improvement with hackbench, but hackbench is very unreliable for such tests. I'm hoping others will run it under their work loads to see how things improve. > > It might be better to improve gcc to move really cold branches out of > line (really, really far away), and use the compiler to do this, rather > than to use an extra indirection that adds bloat and complexity to the > kernel. I think modifying gcc is something that can help more than tracing. But that's been a pipe dream for such a long time that I've started dreaming about winning a gold medal in the Olympics instead. Standing on the podium listening to the crowd chanting your name along with your country is more fun to dream about than seeing your unlikely code stop becoming hurdles for the CPU sprinters. Yes, I had a bit of Olympic overdose lately. -- Steve