Date: Tue, 22 Jul 2003 17:25:51 -0700 From: David Schultz <das@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: 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 Message-ID: <20030723002551.GA10353@HAL9000.homeunix.com> In-Reply-To: <16474.1058916504@critter.freebsd.dk> References: <20030722231656.GA9715@HAL9000.homeunix.com> <16474.1058916504@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 23, 2003, Poul-Henning Kamp wrote: > In message <20030722231656.GA9715@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030723002551.GA10353>