From owner-cvs-src@FreeBSD.ORG Tue Jul 22 15:39:15 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 C02EB37B404 for ; Tue, 22 Jul 2003 15:39:15 -0700 (PDT) Received: from mail26a.sbc-webhosting.com (mail26a.sbc-webhosting.com [216.173.237.164]) by mx1.FreeBSD.org (Postfix) with SMTP id CD22143F93 for ; Tue, 22 Jul 2003 15:39:13 -0700 (PDT) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21)4-0539423539; Tue, 22 Jul 2003 18:38:59 -0400 (EDT) Sender: alc@FreeBSD.ORG Message-ID: <3F1DBD05.A4886D5E@imimic.com> Date: Tue, 22 Jul 2003 17:39:01 -0500 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp References: <15381.1058909578@critter.freebsd.dk> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 22:39:16 -0000 Poul-Henning Kamp wrote: > > In message <3F1DA5B9.A877E8D9@imimic.com>, "Alan L. Cox" writes: > > >I chose my example very carefully... > ... > To take your example vm_object_backing_scan(), lets run it through > the mill: > > GCC has until now ignored the request to inline this function, and > neither you, I nor anybody else noticed that (Well, OK... Bruce > may have noticed :-) Now GCC tells us that it ignores it, and we > want to make an informed decision if we want to force it to be > inlined or if GCC was right, after all. I've known about this for several months. :-) (That's why I knew about the "always inline" directive.) > Your reasoning about common and constant subexpression elimination > is a very reasonable and convincing argument for inlining it. > > Compiling the file with and without the inline, and forcing GCC > to respect the inline finds: > > text data bss dec hex filename > inlined: 17408 76 420 17904 45f0 vm_object.o > regular: 14944 76 420 15440 3c50 vm_object.o > ----- > 2464 > > At least I find that 2k+ code is a non-trivial amount which is > likely, through prefetch and cache flushing, to have a negative > performance impact. > > Given two conflicting arguments, we need to resort to reality for > the answer, and what we need to reinstate the inline on an informed > basis is a realistic benchmark which indicates a positive performance > impact of the (respected) inline request. > > Until we have that benchmark, the inline has been removed because > that retains the status quo and puts us closer to being able to get > the kernel -Werror again (by raising the inline-limit) without > bloating the kernel text segment with 100k+ produced by inlines > which may not be beneficial. > In general, I agree with you that a vast majority of the inlines should be removed. We should, however, have an override for exceptional cases. Again, in the case of vm_object_backing_scan(), code size is a bad predictor of inlining's effect. Inlining is being used to achieve a form of code specialization that will actually reduce the size of the code that is *executed*. In conclusion, my point is not that you should stop what you're doing. It is rather that there are exceptional cases where gcc is doing the wrong thing and we should have an override to force inlining that can be applied. Alan