* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > 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. >
I agree that turning this flag on does not seem like an interesting solution. Well, I wonder how important this issue of not sharing L1 instruction cachelines with scheduler code is. If we care as much about it as Ingo states, I wonder why we leave about 22 BUG() macros in sched.c (calculated from the number of ud2 instructions generated on x86), which adds up to 7 bytes at the end of many scheduler functions (7 bytes coming from ud2, jmp and .p2align on x86). And 22 markers in sched.c is already much more than needed. I actually propose only 5 in my patchset. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
