HEADS UP Re: cvs commit: src/sys/conf options.i386 src/sys/i386/i386 bios.c locore.s machdep.c mpboot.s pmap.c vm86bios.s vm_machdep.c src/sys/i386/include _types.h bus_at386.h param.h pmap.

[Jake Burkholder]

Apparently, On Mon, Mar 31, 2003 at 05:12:39PM +1000,
	Peter Jeremy said words to the effect of;

> On Sun, Mar 30, 2003 at 06:20:30PM -0500, Jake Burkholder wrote:
> >Apparently, On Sun, Mar 30, 2003 at 03:30:52PM -0600,
> >	Mike Silbersack said words to the effect of;
> >> Is it practically possible with PAE and busdma'd drivers that such a
> >> configuration could work?
> >
> >I'm not sure I understand the question, you mean is it possible to use
> >separate address spaces for the kernel and userland, giving a full 4G each?
> >Yes it is possible, but it is not practical.
> 
> Why do you say "not practical"?  Unix spent most of its formative
> years with kernel and userland in separate address spaces.  I don't
> think the code exists in 4BSD but it's definitely still functional
> in 2BSD (which is under a BSD license now-a-days).

x86 just doesn't lend itself well to doing this.  The sparc64 port uses
separate address spaces because it is easy there.  Its not a matter of
the os supporting it, its what you can do realistically with the hardware.

> 
> >  It would be prohibitively expensive and ugly.
> 
> I'll accept "ugly" and "expensive".  The "prohibitively" is more of a
> value judgement.  Currently FreeBSD needs to trade KVA against UVA for
> large RAM configurations.  If you have an application that needs lots
> of KVA and lots of UVA then FreeBSD on x86 isn't currently an option.
> Wearing the overheads on system calls, copyin and copyout may be
> cheaper than the alternatives.

Don't let me stop you from implementing it.

Jake