From owner-cvs-all  Tue Jun 26 10:36:20 2001
Delivered-To: cvs-all@freebsd.org
Received: from sneakerz.org (sneakerz.org [216.33.66.254])
	by hub.freebsd.org (Postfix) with ESMTP
	id 2359837B401; Tue, 26 Jun 2001 10:36:11 -0700 (PDT)
	(envelope-from bright@sneakerz.org)
Received: by sneakerz.org (Postfix, from userid 1092)
	id 9A8CC5D010; Tue, 26 Jun 2001 12:36:10 -0500 (CDT)
Date: Tue, 26 Jun 2001 12:36:10 -0500
From: "Jonathan Lemon <jlemon@flugsvamp.com>    Alfred Perlstein" <bright@sneakerz.org>
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: "Brian F. Feldman" <green@FreeBSD.org>,
	Mike Silbersack <silby@silby.com>,
	Matt Dillon <dillon@earth.backplane.com>,
	Mike Silbersack <silby@FreeBSD.org>, cvs-committers@FreeBSD.org,
	cvs-all@FreeBSD.org, jlemon@FreeBSD.org, bmilekic@FreeBSD.org
Subject: Re: cvs commit: src/sys/netinet tcp_input.c tcp_output.c tcp_subr.c tcp_timer.c tcp_usrreq.c tcp_var.h
Message-ID: <20010626123610.M64836@sneakerz.org>
References: <200106261707.f5QH70k41274@green.bikeshed.org> <75438.993576676@critter>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <75438.993576676@critter>; from phk@critter.freebsd.dk on Tue, Jun 26, 2001 at 07:31:16PM +0200
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

* Poul-Henning Kamp <phk@critter.freebsd.dk> [010626 12:31] wrote:
> In message <200106261707.f5QH70k41274@green.bikeshed.org>, "Brian F. Feldman" w
> rites:
> 
> >Well, I don't get exactly how it would be optimized more than it is now 
> >because it won't be able to take advantage of these "smaller" bzero()s... 
> >unless... what about making malloc() an inline that checks M_ZERO and uses 
> >the new constant-bzero() on sufficiently small sizes after calling malloc 
> >without the M_ZERO?  I'm pretty certain GCC would optimize that fine, and 
> >that would buy us the faster-constant-sized-bzero back from the M_ZERO 
> >optimization.
> 
> I seriously doubt you'd get any optimization out of doing it in
> general.  It would probably be better to _not_ use M_ZERO if in
> some particular case of allocation you need the speed of the
> optimized bzero().
> 
> But if you need the optimized bzero() that bad, what are you
> doing calling malloc in the first place ?

We could put the test for size in the macro portion then deciding
to M_ZERO or not along with which version would be optimized out
by the compiler for constants.

-Alfred

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message