Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753477AbZDVGDs (ORCPT ); Wed, 22 Apr 2009 02:03:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752221AbZDVGDj (ORCPT ); Wed, 22 Apr 2009 02:03:39 -0400 Received: from one.firstfloor.org ([213.235.205.2]:38498 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752194AbZDVGDi (ORCPT ); Wed, 22 Apr 2009 02:03:38 -0400 Date: Wed, 22 Apr 2009 08:07:01 +0200 From: Andi Kleen To: Steven Rostedt Cc: Andi Kleen , 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 Message-ID: <20090422060701.GB14687@one.firstfloor.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1106 Lines: 31 > 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. -Andi -- ak@linux.intel.com -- Speaking for myself only. -- 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/