Date: Sat, 08 Nov 1997 21:21:50 +1030 From: Mike Smith <mike@smith.net.au> To: Jonathan Mini <mini@d198-232.uoregon.edu> Cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG Subject: Re: x86 gods; advice? Suggestions? Message-ID: <199711081051.VAA00966@word.smith.net.au> In-Reply-To: Your message of "Sat, 08 Nov 1997 02:49:58 -0800." <19971108024958.28488@micron.mini.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Two possible solutions; use a coprocess running the vm86 thread as a > > sort of "graphics processor" (involves a context switch between > > operations, but you could stack them), or wait for the vm86 sysarch() > > stuff that comes with the vm86 stuff I am working on. (Kernel entry > > and two context switches per call.) > > That is how I originally planned writing the code. I am working on a method > that uses vfork(2) to see if it is any faster/slower/doesn't-make-a-difference. Don't use vfork; it sucks. Use popen() and a dedicated graphics processor process. Note that the FreeBSD pipe code has some odd behavioural quirks; most particularly the more you can write in a single hit, the faster it is. This is especially the case if you are writing a large amount of data in a stream between processes. If you're writing from scattered buffers, using writev() is an *enormous* win. > Not much is really done in the vm86 task, just calls to do things like set the > video mode and such. "And such" doesn't include anything particularly speed critical? mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711081051.VAA00966>