From owner-freebsd-hackers Tue Feb 16 10:24: 4 1999 Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18555 for ; Tue, 16 Feb 1999 10:24:02 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA37290; Tue, 16 Feb 1999 10:23:41 -0800 (PST) (envelope-from dillon) Date: Tue, 16 Feb 1999 10:23:41 -0800 (PST) From: Matthew Dillon Message-Id: <199902161823.KAA37290@apollo.backplane.com> To: perlsta Cc: Kevin Day , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: vm_page_zero_fill References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > 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. 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. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message