[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.00.0801140824430.2806@woody.linux-foundation.org>
Date: Mon, 14 Jan 2008 08:30:07 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc: Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...e.hu>,
"Frank Ch. Eigler" <fche@...hat.com>,
"K. Prasad" <prasad@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, linux-rt-users@...r.kernel.org,
dipankar@...ibm.com, ego@...ibm.com, paulmck@...ux.vnet.ibm.com,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/2] Markers Implementation for Preempt RCU Boost
Tracing
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists