* Andrew Morton <[email protected]> wrote:
> Ingo Molnar <[email protected]> wrote:
> >
> > I think gcc should arguably not be forced to inline things when doing
> > -Os, and it's also expected to mess up much less than when optimizing
> > for speed. So maybe forced inlining should be dependent on
> > !CONFIG_CC_OPTIMIZE_FOR_SIZE?
>
> When it comes to inlining I just don't trust gcc as far as I can spit
> it. We're putting the kernel at the mercy of future random brainfarts
> and bugs from the gcc guys. It would be better and safer IMO to
> continue to force `inline' to have strict and sane semamtics, and to
> simply be vigilant about our use of it.
i think there's quite an attitude here - we are at the mercy of "gcc
brainfarts" anyway, and users are at the mercy of "kernel brainfarts"
just as much. Should users disable swapping and trash-talk it just
because the Linux kernel used to have a poor VM? (And the gcc folks are
certainly listening - it's not like they were unwilling to fix stuff,
they simply had their own decade-old technological legacies that made
certain seemingly random problems much harder to attack. E.g. -Os has
recently been improved quite significantly in to-be-gcc-4.2.)
at least let us allow gcc do it in the CONFIG_CC_OPTIMIZE_FOR_SIZE case,
-Os means "optimize for space" - no ifs and when, it's a _very_ clear
and definite goal. I dont think there's much space for gcc to mess up
there, it's a mostly binary decision: either the inlining of a
particular function saves space, or not.
in the other case, when optimizing for speed, the decisions are alot
less clear, and gcc has arguably alot more leeway to mess up.
also, there's a fundamental conflict of 'speed vs. performance' here,
for a certain boundary region. For the extremes, very small and very
large functions, the decision is clear, but if e.g. a CPU has tons of
cache, it might prefer more agressive inlining than if it doesnt. So
it's not like we can do it in a fully static manner.
> If no-forced-inlining makes the kernel smaller then we probably have
> (yet more) incorrect inlining. We should hunt those down and fix them.
> We did quite a lot of this in 2.5.x/2.6.early. Didn't someone have a
> script which would identify which functions are a candidate for
> uninlining?
this is going to be a never ending battle, and it's not about peanuts
either: we are talking about 5% of .text space here, on a .config that
carries most of the important subsystems and drivers. Do we really want
to take on this battle and fight it for 30,000+ kernel functions - when
gcc today can arguably do a _better_ job than what we attempted to do
manually for years? We went to great trouble going to BK just to make
development easier - shouldnt we let a fully open-source tool like gcc
make our lives easier and not worry about details like that? Whether to
inline or not _is_ a mostly thoughtless work with almost zero intellect
in it. I'd rather trust gcc do it than some script doing the same much
worse.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
