From owner-cvs-all Mon Jun 25 7:15:16 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A75F437B405; Mon, 25 Jun 2001 07:15:02 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA14091; Tue, 26 Jun 2001 00:14:37 +1000 Date: Tue, 26 Jun 2001 00:12:43 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Matt Dillon Cc: Peter Wemm , Mikhail Teterin , jlemon@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: kernel size w/ optimized bzero() & patch set (was Re: Inline optimized bzero (was Re: cvs commit: src/sys/netinettcp_subr.c)) In-Reply-To: <200106250134.f5P1YsN01440@earth.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 24 Jun 2001, Matt Dillon wrote: [Peter Wemm wrote] > :Just think.. This new ``improved'' bzero code can now fill up all 4K of L1 > :instruction cache on most of my systems, and most of my 8K L1 instruction > :cache on >= coppermine cpus. I'm impressed. Those microbenchmarks had > > Huh? Peter, you obviously haven't been listening. I strongly recommend > that you review the last few postings I've made. The suggested bzero > code certainly does NOT in any way blow up the L1 cache, and I think > I'm pretty clear on that. I wouldn't be doing it if it did. It was an intermediate version that blew up the cache. I have been trying slightly different versions, and found that gcc's builtin version doesn't make all that much difference in the code size, either up or down. With the following version of bzero: #define bzero(p, n) ({ \ if (__builtin_constant_p(n) && (n) <= X) \ __builtin_memset((p), 0, (n)); \ else \ (bzero)((p), (n)); \ }) for X = 0, 4, 8, 12, 16, 32 and "infinity", the kernel sizes were: text data bss dec hex filename 1962434 151436 349824 2463694 2597ce kernel.4 1962442 151436 349824 2463702 2597d6 kernel.8 1962446 151436 349824 2463706 2597da kernel.12 1962466 151436 349824 2463726 2597ee kernel.0 1962802 151436 349824 2464062 25993e kernel.16 1962866 151436 349824 2464126 25997e kernel.20 1963538 151436 349824 2464798 259c1e kernel.32 1964098 151436 349824 2465358 259e4e kernel.infinity Summary: it's hard for the inline version to be smaller; even when it only needs to do one store-immediate operation, the kernel is only 32 bytes smaller than the one using function calls which have to push 2 args, do the call, and clean up. This is presumably due to increased register pressure for the inlined versions. OTOH, the recent uninlining of the mbuf macros somehow reduced the size of my standard kernel by more than 5% (more than 100K). It also reduced the compilation time by more than 10%. Kernel compilation times are still 65% larger than in RELENG_3 for kernels with essentially the same options (this is using -current's compiler; they are 85% larger using RELENG_3's compiler). > :better be damn good, because it may end up the only thing that the system > :will do well now since all this excessive inlining looks like it is blowing > :the L1 cache out the door. > : > :(I also apply the same complaint to the vm/* inlines). > > And you are just as wrong. The few functions inlined in vm/* are inlined > mainly because (A) they are called with constant arguments, which means Some seem to have rotted a bit. E.g., _vm_map_lock_upgrade() (adding an mtx_lock() to anything will bloat it in both space and time). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message