From owner-cvs-all@FreeBSD.ORG Tue Jul 22 16:28:35 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8870437B401; Tue, 22 Jul 2003 16:28:35 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62DBD43F3F; Tue, 22 Jul 2003 16:28:34 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6MNSPV3031128; Tue, 22 Jul 2003 23:28:25 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6MNSO5H016475; Wed, 23 Jul 2003 01:28:24 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 16:16:56 PDT." <20030722231656.GA9715@HAL9000.homeunix.com> Date: Wed, 23 Jul 2003 01:28:24 +0200 Message-ID: <16474.1058916504@critter.freebsd.dk> cc: "Alan L. Cox" cc: src-committers@FreeBSD.ORG cc: Bosko Milekic cc: Bruce Evans cc: cvs-src@FreeBSD.ORG cc: Steve Kargl cc: cvs-all@FreeBSD.ORG cc: Marcel Moolenaar 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 23:28:35 -0000 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.