From owner-freebsd-hackers Tue Feb 16 14:47:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 0DAFF10EA0 for ; Tue, 16 Feb 1999 14:47:09 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA23404; Tue, 16 Feb 1999 15:58:31 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpd023268; Tue Feb 16 15:58:21 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA08400; Tue, 16 Feb 1999 15:46:46 -0700 (MST) From: Terry Lambert Message-Id: <199902162246.PAA08400@usr08.primenet.com> Subject: Re: vm_page_zero_fill To: dyson@iquest.net Date: Tue, 16 Feb 1999 22:46:46 +0000 (GMT) Cc: toasty@home.dragondata.com, mike@smith.net.au, hackers@FreeBSD.ORG In-Reply-To: <199902160441.XAA00469@y.dyson.net> from "John S. Dyson" at Feb 15, 99 11:41:25 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Perhaps a change that would allow for malloc()'ed and new'ed memory to be > > able to take memory from the to-be-zero'ed list would be better, although > > that may be more work than I'm looking for.... > > That *might* be reasonable. A special sbrk or somesuch. That sbrk > would make a non-prezeroed map entry. vm_fault would just avoid > doing the zero. Expecting sbrk'ed pages to be zero filled is just *wrong*. Sorry, but there is a *reason* that there are seperate malloc(3) and calloc(3) routines. The former is seperate from the latter because uncleared pages are supposed to occur faster, and because there was an expectation that the malloc(3) could return space already allocated to the process. Indeed, the ANSI C specification practically *prohibits* breaking memory back to the system, since it *requires* that a free'd region of a given size be re-malloc'able without a check of the malloc return code (though it doesn't guarantee contents). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message