Date: Wed, 23 Jul 2003 01:28:24 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: David Schultz <das@FreeBSD.ORG> 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: <16474.1058916504@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 22 Jul 2003 16:16:56 PDT." <20030722231656.GA9715@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >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. 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 The first table should be self explanatory. The table at the bottom has three fields: last limit where GCC refused the inlining name of functions calls to funcion. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16474.1058916504>