Date: Mon, 15 Feb 1999 21:44:21 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: mike@smith.net.au (Mike Smith) Cc: hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902160344.VAA19696@home.dragondata.com> In-Reply-To: <199902160329.TAA14312@dingo.cdrom.com> from Mike Smith at "Feb 15, 1999 7:29:43 pm"
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. > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902160344.VAA19696>