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
jake at locore.ca
Mon Mar 31 00:14:09 PST 2003
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.
More information about the cvs-src