Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752951AbYANQcj (ORCPT ); Mon, 14 Jan 2008 11:32:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750868AbYANQca (ORCPT ); Mon, 14 Jan 2008 11:32:30 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:55581 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750744AbYANQc3 (ORCPT ); Mon, 14 Jan 2008 11:32:29 -0500 Date: Mon, 14 Jan 2008 08:30:07 -0800 (PST) From: Linus Torvalds To: Mathieu Desnoyers cc: Pavel Machek , Ingo Molnar , "Frank Ch. Eigler" , "K. Prasad" , linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, dipankar@in.ibm.com, ego@in.ibm.com, paulmck@linux.vnet.ibm.com, Andrew Morton Subject: Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing In-Reply-To: <20080114153505.GA11522@Krystal> Message-ID: References: <20071231060911.GB6461@in.ibm.com> <20071231102045.GB30380@elte.hu> <20080102124734.GC11208@elte.hu> <20080102163309.GC11496@redhat.com> <20080102170157.GA11161@elte.hu> <20080107185954.GA16041@Krystal> <20080113180740.GA4435@ucw.cz> <20080114153505.GA11522@Krystal> User-Agent: Alpine 1.00 (LFD 882 2007-12-20) 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: 1210 Lines: 31 On Mon, 14 Jan 2008, Mathieu Desnoyers wrote: > > We would have to figure out if enabling -freorder-blocks-and-partition > makes sense kernel-wide. Last I saw, it generates crappy code, with lots more jumps back and forth, and the image just blows up. There's a reason we use -Os, and that's that small footprint I$ is generally more important than fake compiler optimizations that don't actually help except on microbenchmarks where everything fits in the cache. Taking a branch instruction from two bytes to five is almost always a mistake, unless you *know* that the code it jumps to will effectively never be done at all (which is not necessarily the case at all). It also makes debugging much nastier, because if now things like backtraces probably look like crap too! Don't go there. The *best* we can do is to just use the optimizations that generate good-looking code that humans can read. The rest is just compiler masturbation. 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/