cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c

[David Schultz]

On Wed, Jul 23, 2003, Poul-Henning Kamp wrote:
> In message <20030722231656.GA9715 at HAL9000.homeunix.com>, David Schultz writes:
> 
> Please remember that the problem at hand is getting -Werror back
> on the kernel so we can catch issues like the warning in umtx.
> 
> We could either do that by lobotomizing the warning in the compiler
> or by setting the limit high enough to inline everything so marked.
> 
> Since the warning has indeed pointed out a fair number of bogus
> inlines, the first option did not seem attractive.

I would just as soon make gcc always inline, and fix the places
where the programmer really screwed up.  It would be nice if there
were a way to get gcc to generate a warning for new code with
expensive inlines, but have a way to disable the warning on a
case-by-case basis.  (I think you mentioned something like this a
little while ago.)

> >Actually, it might be interesting to make a list of all the
> >functions in the kernel that contain inline calls sorted by the
> >bytes of bloat.  Then for all those grey areas, developers could
> >be asked to look at the list and reconsider their use of inlines,
> >and you wouldn't have to waste your talent trying to evaluate each one.
> 
> This is more or less what I have been spending my day doing, only
> I used the GCC metric as indication to target the most likely
> offenders.
> 
> My experiments have shown that if we had just raised the limit high
> enough to inline everything that we have marked as inline, the
> GENERIC kernel text segment would have grown by more than 100 k.

100K out of a 2 MB text segment isn't necessarily too bad, but it
depends where the 100K is.  Note that Intel's own compiler inlines
fairly aggressively (and even supports partial inlining based on
profiling data), and the guys at Intel aren't dummies.  Inlining
can be quite effective even when it does increase the size of the
code, as Peter and others have already discussed.  In non-obvious
cases, you either have to understand the code in question or do
some serious benchmarking.

> The inlines I have removed today have all been inlines which GCC
> has previously ignored and which added significant code segment
> size, typically 2k+.
> 
> You can see some of my raw data here: http://phk/misc/inline.txt

Cool.  It looks like gcc's estimation of __asm is way off for some
reason.

I still suggest that you only fix the ones that are obviously
wrong and nudge various maintainers about the rest if you really
care.  A number of people are not convinced that some of the
uninlining you've done so far is appropriate or worth your time.
Besides, then you don't have to listen to all of us telling you
what color to paint the bikeshed.  ;-)

It would also be interesting to do this sort of analysis in
userland, where there is often less concern about performance and
more concern about code size.  If I finish $realwork before
midnight, I'll see if I can come up with a good way to get at raw
function sizes for userland with/without inlines and spit out the
results in a useful way.
_______________________________________________
cvs-all at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe at freebsd.org"