Date: Tue, 16 Feb 1999 03:40:15 -0600 (CST) From: Kevin Day <toasty@home.dragondata.com> To: bright@cygnus.rush.net (perlsta) Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <199902160940.DAA02860@home.dragondata.com> In-Reply-To: <Pine.BSF.3.96.990216043855.10060t-100000@cygnus.rush.net> from perlsta at "Feb 16, 1999 4:50:39 am"
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). > > > > > > 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? I'm DMA'ing everything that I can practically DMA, but I believe my problem is running out of bandwidth, not CPU at this point. > > 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. I'm doing this whenever practical. Without really saying too much about a product that isn't announced, I can say that it's one device with 15-20 seperate applications in it, that wouldn't do well to be all one giant process. We're sorely out of memory bandwidth, so any memory use we can cut down on is a big win. This is my rationale. > > 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. :) I started doing this, but it looked like more work than it would be worth. I also wasn't sure if those sorts of changes would be committed, since (to requote): > > > the C spec says that the BSS contains zeroes, so it's > > > typically assumed that all unitialised globals will be zeroed. If this is something that can be relied upon, why add implicit zero's in the code? I may end up making changes to the tools we use, if I go this route, but is that something that the majority would feel to be worthwhile? > > Why does your graphical application run inetd? :) > It doesn't, but we use inetd to launch telnetd for debugging. :) 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?199902160940.DAA02860>