Date: Tue, 16 Feb 1999 12:49:59 -0500 (EST) From: perlsta <bright@cygnus.rush.net> To: Kevin Day <toasty@home.dragondata.com> Cc: mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill Message-ID: <Pine.BSF.3.96.990216122756.10060u-100000@cygnus.rush.net> In-Reply-To: <199902160940.DAA02860@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 Feb 1999, Kevin Day wrote: > > > 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. I meant DMA'ing zero's into pages, but if you don't think that it's CPU then this may not help. > > 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. This is my rationale here as well, you say you need performance but yet you aren't willing to meet halfway. You do NOT need to combine all your modular programs into a single large monolithic monstrosity, all i'm saying is that you may want to have each smaller program stay resident and answer requests via some sort of IPC mechanism instead of establishing simple pipelines as you constantly fork/exec. You are choosing easy, not 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. :) > > 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): I was sort of kidding about that suggestion. > > > > > 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? because lazy coders have depended on that feature for years now, and changing it would break too many things. not only that but it's nice to know that _some_ things will be zero'd out for you. > 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? *shrug* i'm not a commiter > > > > > Why does your graphical application run inetd? :) > > > > > It doesn't, but we use inetd to launch telnetd for debugging. :) > oh :) -Alfred > > > 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?Pine.BSF.3.96.990216122756.10060u-100000>