From owner-freebsd-hackers  Fri Dec  4 08:39:46 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA21529
          for freebsd-hackers-outgoing; Fri, 4 Dec 1998 08:39:46 -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 IAA21524
          for <hackers@FreeBSD.ORG>; Fri, 4 Dec 1998 08:39:44 -0800 (PST)
          (envelope-from toasty@home.dragondata.com)
Received: (from toasty@localhost)
	by home.dragondata.com (8.8.8/8.8.5) id KAA28408;
	Fri, 4 Dec 1998 10:39:18 -0600 (CST)
From: Kevin Day <toasty@home.dragondata.com>
Message-Id: <199812041639.KAA28408@home.dragondata.com>
Subject: Re: Nonblocking page fetching
In-Reply-To: <199812041308.OAA08387@labinfo.iet.unipi.it> from Luigi Rizzo at "Dec 4, 1998  2: 8:30 pm"
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Fri, 4 Dec 1998 10:39:18 -0600 (CST)
Cc: 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

> > > > This has some obvious disadvantages, but it stopped my movie player from
> > > > sitting in vmwait when it could be doing other things.
> > > 
> > > is it so bad ? The forked process should consume very little memory
> ...
> > Well, I may be wrong, but I assumed that the CPU involved in just having a
> > kernel bring pages in on it's own would be less. Is there anything that
> > could be saved by putting this in the kernel?
> 
> let's see... you fork a process once so that does not count. Every
> bunch of prefetch requires an IPC, and every page causes a context
> switch (or two ?) following the page fault. This is what you can save.
> I cannot quantify times for all the above activities, maybe someone
> else has some numbers.

Ok, maybe I'm making a bigger deal of it than it is.

> 
> >>> One final note... Does anyone know what effect turning off the bzero on new
> >>> pages would be? Security is not an issue in this system, as it's not
> 
> i think a lot of software will break.

Doesn't that break the golden rule of never assuming the contents of new
memory?

> 
> >> again how bad is it ? bzero is generally done in the idle loop if i am
> ...
> > We are at 100% cpu constantly. When I'm not drawing, i'm prerendering frames
> 
> ok, so think this differently: bzero'ing occurs at memory speed which
> could be around 200-400MB/s in your case, or 10-20us/page.
> 

Without giving away too much information, we're using a unified memory
system, bandwidth usage is of extreme importance.


Kevin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message