Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754135Ab3HERMI (ORCPT ); Mon, 5 Aug 2013 13:12:08 -0400 Received: from mail-ve0-f172.google.com ([209.85.128.172]:50482 "EHLO mail-ve0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752739Ab3HERMG (ORCPT ); Mon, 5 Aug 2013 13:12:06 -0400 MIME-Version: 1.0 In-Reply-To: <1375721715.22073.80.camel@gandalf.local.home> References: <1375721715.22073.80.camel@gandalf.local.home> Date: Mon, 5 Aug 2013 10:12:04 -0700 X-Google-Sender-Auth: BE7950wLo91XKS7cFPs3hayBmEM Message-ID: Subject: Re: [RFC] gcc feature request: Moving blocks into sections From: Linus Torvalds To: Steven Rostedt Cc: LKML , gcc , Ingo Molnar , Mathieu Desnoyers , "H. Peter Anvin" , Thomas Gleixner , David Daney , Behan Webster , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1784 Lines: 41 On Mon, Aug 5, 2013 at 9:55 AM, Steven Rostedt wrote: > > Almost a full year ago, Mathieu suggested something like: > > if (unlikely(x)) __attribute__((section(".unlikely"))) { > ... > } else __attribute__((section(".likely"))) { > ... > } It's almost certainly a horrible idea. First off, we have very few things that are *so* unlikely that they never get executed. Putting things in a separate section would actually be really bad. Secondly, you don't want a separate section anyway for any normal kernel code, since you want short jumps if possible (pretty much every single architecture out there has a concept of shorter jumps that are noticeably cheaper than long ones). You want the unlikely code to be out-of-line, but still *close*. Which is largely what gcc already does (except if you use "-Os", which disables all the basic block movement and thus makes "likely/unlikely" pointless to begin with). There are some situations where you'd want extremely unlikely code to really be elsewhere, but they are rare as hell, and mostly in user code where you might try to avoid demand-loading such code entirely. So give up on sections. They are a bad idea for anything except the things we already use them for. Sure, you can try to fix the problems with sections with link-time optimization work and a *lot* of small individual sections (the way per-function sections work already), but that's basically just undoing the stupidity of using sections to begin with. Linus -- 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/