From owner-cvs-all Sun Jun 24 23:38:32 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 24BB637B406; Sun, 24 Jun 2001 23:38:24 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f5P1YsN01440; Sun, 24 Jun 2001 18:34:54 -0700 (PDT) (envelope-from dillon) Date: Sun, 24 Jun 2001 18:34:54 -0700 (PDT) From: Matt Dillon Message-Id: <200106250134.f5P1YsN01440@earth.backplane.com> To: Peter Wemm Cc: Bruce Evans , 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)) References: <20010625060743.292F7380B@overcee.netplex.com.au> 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 :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. :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). : :Cheers, :-Peter 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 that the resulting code will typically take up no more space then the call that would have been there in the first place, or (B) they do something that only takes a small number of instructions anyway, or (C) they are called so few times that inlining will produce higher performance without eating the L1 cache any more then it would have otherwise. I constructed those inlines very carefully and ran assembly output to make sure they worked the way they were supposed to. Period dot. If you have a problem with it, produce some hard evidence and I will review it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message