Date: Fri, 4 Dec 1998 14:08:30 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: toasty@home.dragondata.com (Kevin Day) Cc: hackers@FreeBSD.ORG Subject: Re: Nonblocking page fetching Message-ID: <199812041308.OAA08387@labinfo.iet.unipi.it> In-Reply-To: <199812041504.JAA04986@home.dragondata.com> from "Kevin Day" at Dec 4, 98 09:04:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. >>> 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. >> 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. luigi 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?199812041308.OAA08387>