Date: Tue, 26 Jun 2001 13:39:45 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: "Brian F. Feldman" <green@FreeBSD.org> Cc: "Jonathan Lemon <jlemon@flugsvamp.com> Alfred Perlstein" <bright@sneakerz.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: <71068.993555585@critter> In-Reply-To: Your message of "Sun, 24 Jun 2001 17:41:38 EDT." <200106242141.f5OLfc176777@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200106242141.f5OLfc176777@green.bikeshed.org>, "Brian F. Feldman" w rites: >> bzero seems to be optimized for large areas, perhaps it would help >> malloc some if we used some alternative zero'ing function for small >> allocations with M_ZERO set? > >That's pretty pointless; M_ZERO is _supposed_ to eventually be providing >pre-zeroed memory, which should remove that bzero in the general case, >anyway. Well, M_ZERO was designed to remove a lot of distinct calls to bzero in the hope that we could: A) collect statistics showing if demand for zeroed RAM is big enough to persue B) B) Implement prezeroed RAM as an optimization. Neither of these precludes an optimization of the current implementation of M_ZERO -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?71068.993555585>