Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752758AbZDVGYc (ORCPT ); Wed, 22 Apr 2009 02:24:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751212AbZDVGYW (ORCPT ); Wed, 22 Apr 2009 02:24:22 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:37499 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751029AbZDVGYV (ORCPT ); Wed, 22 Apr 2009 02:24:21 -0400 Date: Wed, 22 Apr 2009 02:24:17 -0400 (EDT) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Andi Kleen cc: Jeremy Fitzhardinge , Mathieu Desnoyers , linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Thomas Gleixner , Peter Zijlstra , Frederic Weisbecker , Theodore Tso , Arjan van de Ven , Christoph Hellwig , Lai Jiangshan , Zhaolei , Li Zefan , KOSAKI Motohiro , Masami Hiramatsu , "Frank Ch. Eigler" , Tom Zanussi , Jiaying Zhang , Michael Rubin , Martin Bligh , Peter Zijlstra , Neil Horman , Eduard - Gabriel Munteanu , Pekka@firstfloor.org Subject: Re: [PATCH 2/8] tracing: create automated trace defines In-Reply-To: <20090422060701.GB14687@one.firstfloor.org> Message-ID: References: <49E6065B.7080409@goop.org> <20090416023456.GC22378@Krystal> <49E69E76.9030608@goop.org> <20090416234410.GA20513@Krystal> <87zlebpzmk.fsf@basil.nowhere.org> <20090421155106.GE3792@Krystal> <49EDFFE6.1080401@goop.org> <20090421202828.GB32179@basil> <20090422060701.GB14687@one.firstfloor.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2148 Lines: 55 On Wed, 22 Apr 2009, Andi Kleen wrote: > > I think it was Ingo that let out the idea, and I'm starting to like it. > > > > Perhaps we should fork off gcc and ship Linux with its own compiler. This > > way we can optimize it for the kernel and not worry about any userland > > optimizations. > > > > I would like to do something like: > > > > if (unlikely(err)) { > > __section__(".error_sect") { > > > gcc already supports that, you don't need to fork anything. It's called > hot/cold partitioning. Basically it splits functions into hot and cold > and unlikely parts and all the cold/unlikely parts go into a separate > sections. > > I think it's normally not enabled by default on x86 though, probably because > it doesn't help too much. > > By default (unless you specify -fno-reorder-blocks) it does the same > without sections, just moving unlikely code out of line. The unlikely code does not always get moved out that far. It still sits inside a function, and looking at the tracepoint code it did not move it far enough. If you have a bunch of functions that each with an unlikely statement, those unlikely sections will still be interleaved within the function code. In the case of tracepoints, it would be nice to move all the code that sets up the function call out of the hot paths. If we could move it to its own section, that would be much better. Having all "unlikely"s go into a separate section would not help much, since according to the branch profiler there are a lot of "unlikely"s in the kernel that are not too unlikely. If gcc can indeed move "unlikely" code completely out of the fast path, and put it into its own sections, then I think we should go through the kernel and start removing all "likely" and "unlikely"s that are not 99% accurate. Then we can enable the separate section cold paths and perhaps see a performance benefit. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/