Date: Mon, 15 Feb 1999 19:29:43 -0800 From: Mike Smith <mike@smith.net.au> To: Kevin Day <toasty@home.dragondata.com> Cc: hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902160329.TAA14312@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 15 Feb 1999 17:50:48 CST." <199902152350.RAA04318@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902160329.TAA14312>