From owner-cvs-src@FreeBSD.ORG Tue Jul 22 17:36:17 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0F8D37B401; Tue, 22 Jul 2003 17:36:16 -0700 (PDT) Received: from skyline.ome.meisei-u.ac.jp (skyline.ome.meisei-u.ac.jp [160.194.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EB743FB1; Tue, 22 Jul 2003 17:36:14 -0700 (PDT) (envelope-from root@skyline.ome.meisei-u.ac.jp) Received: from skyline.ome.meisei-u.ac.jp (localhost [127.0.0.1]) id h6N0aA1U017101; Wed, 23 Jul 2003 09:36:10 +0900 (JST) Received: (from root@localhost)h6N0a9i7017100; Wed, 23 Jul 2003 09:36:09 +0900 (JST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by ns.meisei-u.ac.jp (8.12.9/8.12.9) with ESMTP id h6N0QakN065275 for ; Wed, 23 Jul 2003 09:26:36 +0900 (JST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id B7221564F1; Tue, 22 Jul 2003 17:26:09 -0700 (PDT) (envelope-from owner-cvs-all@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A0E8237B407; Tue, 22 Jul 2003 17:26:08 -0700 (PDT) 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 10B0737B401; Tue, 22 Jul 2003 17:25:58 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39F1C43F93; Tue, 22 Jul 2003 17:25:57 -0700 (PDT) (envelope-from das@FreeBSD.org) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h6N0PqhC010489; Tue, 22 Jul 2003 17:25:52 -0700 (PDT) (envelope-from das@FreeBSD.org) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h6N0PpIX010488; Tue, 22 Jul 2003 17:25:51 -0700 (PDT) (envelope-from das@FreeBSD.org) Date: Tue, 22 Jul 2003 17:25:51 -0700 From: David Schultz To: Poul-Henning Kamp Message-ID: <20030723002551.GA10353@HAL9000.homeunix.com> Mail-Followup-To: Poul-Henning Kamp , "Alan L. Cox" , Marcel Moolenaar , Steve Kargl , Bosko Milekic , Bruce Evans , cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org References: <20030722231656.GA9715@HAL9000.homeunix.com> <16474.1058916504@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16474.1058916504@critter.freebsd.dk> X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-cvs-all@freebsd.org Errors-To: owner-cvs-all@freebsd.org X-Virus-Scanned: by amavisd-milter (http://amavis.org/) cc: "Alan L. Cox" cc: src-committers@freebsd.org cc: Bosko Milekic cc: Steve Kargl cc: cvs-src@freebsd.org cc: Bruce Evans 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-src@freebsd.org List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 00:36:17 -0000 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. _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"