From owner-cvs-all Tue Jun 26 10: 7:14 2001 Delivered-To: cvs-all@freebsd.org Received: from green.bikeshed.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D8A8637B406; Tue, 26 Jun 2001 10:07:02 -0700 (PDT) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.2/8.11.1) with ESMTP id f5QH70k41274; Tue, 26 Jun 2001 13:07:01 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200106261707.f5QH70k41274@green.bikeshed.org> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: Poul-Henning Kamp Cc: "Brian F. Feldman" , "Jonathan Lemon Alfred Perlstein" , Mike Silbersack , Matt Dillon , Mike Silbersack , 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 In-Reply-To: Message from Poul-Henning Kamp of "Tue, 26 Jun 2001 13:39:45 +0200." <71068.993555585@critter> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jun 2001 13:07:00 -0400 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 Poul-Henning Kamp wrote: > 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 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. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message