From owner-freebsd-hackers  Fri Dec  4 07:05:34 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id HAA09598
          for freebsd-hackers-outgoing; Fri, 4 Dec 1998 07:05:34 -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 HAA09589
          for <hackers@FreeBSD.ORG>; Fri, 4 Dec 1998 07:05:31 -0800 (PST)
          (envelope-from toasty@home.dragondata.com)
Received: (from toasty@localhost)
	by home.dragondata.com (8.8.8/8.8.5) id JAA04986;
	Fri, 4 Dec 1998 09:04:38 -0600 (CST)
From: Kevin Day <toasty@home.dragondata.com>
Message-Id: <199812041504.JAA04986@home.dragondata.com>
Subject: Re: Nonblocking page fetching
In-Reply-To: <199812041248.NAA08298@labinfo.iet.unipi.it> from Luigi Rizzo at "Dec 4, 1998  1:48:36 pm"
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Fri, 4 Dec 1998 09:04:38 -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

> > I have an application where I'm streaming large amounts of data from disk,
> ...
> > The hack I ended up using was another process that I could tell that I
> > needed the frames, and all it did was sit in a for loop touching every page,
> > to force them to be brought in.
> > 
> > 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
> and because they are local you can even resort to or some cheap
> local IPC mechanism to synchronize them. From a portability point of
> view i think this is going to be to be better than provide a
> specialised syscall.

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?

> 
> > 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
> 
> again how bad is it ? bzero is generally done in the idle loop if i am
> not mistaken so you should not be affected too badly by that unless you
> are at or near 100% CPU usage.
> 

We are at 100% cpu constantly. When I'm not drawing, i'm prerendering frames
as far ahead as I can, as well as dealing with picky hardware that must be
polled.

Kevin

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