From owner-freebsd-hackers Mon Feb 15 19:44:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22538 for freebsd-hackers-outgoing; Mon, 15 Feb 1999 19:44:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22530 for ; Mon, 15 Feb 1999 19:44:35 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id VAA19696; Mon, 15 Feb 1999 21:44:22 -0600 (CST) From: Kevin Day Message-Id: <199902160344.VAA19696@home.dragondata.com> Subject: Re: vm_page_zero_fill In-Reply-To: <199902160329.TAA14312@dingo.cdrom.com> from Mike Smith at "Feb 15, 1999 7:29:43 pm" To: mike@smith.net.au (Mike Smith) Date: Mon, 15 Feb 1999 21:44:21 -0600 (CST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 > > > > I'm currently playing with FreeBSD in an embedded system, where security is > > of no concern. The system I'm using has relatively poor memory bandwidth, so > > I was looking for places to optimize. I know how the vm system zeros pages > > before giving them to me, which isn't really necessary. (I'm not sure about > > other software on the fbsd distribution, but all code I've written expects > > malloc(), new, etc to have garbage in them, not be zeroed) > > > > I don't pretend to understand the VM system, but as a quick test, I made > > vm_page_zero_fill a NOP. (This seemed like where this was getting done). > > > > The system ran, but inetd, sed and ld kept crashing on sig 11's or 6's. > > Everything else I ran seemed ok though. While I know ther are better ways of > > doing this, am I going to be fighting a huge battle of making the kernel, as > > well as userland tools capable of dealing with nonzero'ed memory, or am I > > seeing a completely different problem? > > It's a bad idea; the C spec says that the BSS contains zeroes, so it's > typically assumed that all unitialised globals will be zeroed. > > In addition, unless you're pounding the system or memory is very tight, > zeroed pages are accumulated in the idle loop, so zeroing them doesn't > actually cost anything. > My problem is that I have virtually 0 idle time. Any time spent idle is rare, as this is a graphical application, and the faster it runs the better. CPU states: 84.0% user, 0.0% nice, 10.7% system, 5.3% interrupt, 0.0% idle 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.... Maybe this isn't the big area for improvement I thought it would be.... Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message