lkml.org 
[lkml]   [2008]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] Markers Implementation for Preempt RCU Boost Tracing
* Linus Torvalds (torvalds@linux-foundation.org) 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


\
 
 \ /
  Last update: 2008-01-14 20:45    [W:0.068 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site