From owner-freebsd-hackers Tue Feb 16 11:51:51 1999 Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26051 for ; Tue, 16 Feb 1999 11:51:45 -0800 (PST) (envelope-from bright@cygnus.rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.8.7/8.8.7) with SMTP id OAA23318; Tue, 16 Feb 1999 14:07:32 -0500 (EST) Date: Tue, 16 Feb 1999 14:07:30 -0500 (EST) From: perlsta To: Matthew Dillon cc: Kevin Day , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill In-Reply-To: <199902161823.KAA37290@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 16 Feb 1999, Matthew Dillon wrote: > :> > 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. > > If his problem is memory bandwidth, DMA won't help. Yes, this is what i said, 'it may not help' > If this is a turnkey application then there shouldn't be a page zeroing > problem at all unless the application requires programs to be exec'd > all over the place ( like a couple of times a second or worse ). If > the application does not require a lot of program execing, then there > are plenty of ways to mitigate the zeroing - in fact, the standard > malloc()/free() already does it within the life of a process. This is why i suggested daemonizing the processes into a client/server model instead of fork/exec. Needless to say this would be a very interesting project. :) I love evil constraints. -Alfred > > -Matt > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message