From owner-freebsd-hackers Tue Feb 16 01:40:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA27882 for freebsd-hackers-outgoing; Tue, 16 Feb 1999 01:40:31 -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 BAA27877 for ; Tue, 16 Feb 1999 01:40:30 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id DAA02860; Tue, 16 Feb 1999 03:40:15 -0600 (CST) From: Kevin Day Message-Id: <199902160940.DAA02860@home.dragondata.com> Subject: Re: vm_page_zero_fill In-Reply-To: from perlsta at "Feb 16, 1999 4:50:39 am" To: bright@cygnus.rush.net (perlsta) Date: Tue, 16 Feb 1999 03:40:15 -0600 (CST) Cc: mike@smith.net.au, 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). > > > > > > 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