Date: Tue, 16 Feb 1999 04:50:39 -0500 (EST) From: perlsta <bright@cygnus.rush.net> To: Kevin Day <toasty@home.dragondata.com> Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <Pine.BSF.3.96.990216043855.10060t-100000@cygnus.rush.net> In-Reply-To: <199902160344.VAA19696@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Feb 1999, Kevin Day wrote: > > > > > > 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). > > > > 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 This sounds sort of lame, but have you any spare DMA processors to do your dirty work for you? It will obviously be slow, but you could delay having the processor zero pages until your pre-zero'd pages and DMA pages are exhausted. Another area you may be interested in investigating is reusing memory, why are you forcing the system to give you zero'd pages beyond what it normally needs? Instead of forking and execing you might want to look into persistant daemons that use userland memory pools. If performance is SUCH a concern i'm wondering why you aren't already doing this to minimize this issue. Unix offers an incredibly simple and flexible programming enviornment, not all of the methods available are effecient, if you abuse the ease, don't expect speed. Last suggestion, start compiling things with -Wall, find uninitialized variable references, report them to a commiter who will tidy things up for you. This isn't really feasable, but it'd be nice to have _someone_ doing this. :) Why does your graphical application run inetd? :) -Alfred ( i like my second suggestion, it's what i'd look into ) > > 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 > 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?Pine.BSF.3.96.990216043855.10060t-100000>