Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Jun 2001 18:34:54 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Peter Wemm <peter@wemm.org>
Cc:        Bruce Evans <bde@zeta.org.au>, Mikhail Teterin <mi@aldan.algebra.com>, 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)) 
Message-ID:  <200106250134.f5P1YsN01440@earth.backplane.com>
References:   <20010625060743.292F7380B@overcee.netplex.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
: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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106250134.f5P1YsN01440>