Subject: Re: CVS commit: syssrc/sys/arch/vax/include
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Anders Magnusson <ragge@ludd.luth.se>
List: port-vax
Date: 02/23/2002 14:34:38
>
> > The user page table must be in kernel virtual contiguous memory
>
> Not for the KA620; the KA620 puts P0 and P1 ("user") page tables in
> physical memory, not system virtual memory. (Of course, how much
> anyone not doing highly-custom embedded systems cares about the KA620
> is another story.)
>
Gee, I had luckily forgotten that arch :-)
> > This means that the user page table must have space allocated in the
> > system page table before memory management is turned on.
>
> Not quite. All you need to do is allocate physically contiguous memory
> later and you can move the system page tables around after boot. (That
> may be difficult to do under the assumptions NetBSD's MI code currently
> makes; that's a different issue.)
>
I don't really think it would be realistic to try to implement such
feature :-)
> Also, there's no reason in principle that the system page table can't
> have holes - invalid PTEs (or perhaps they have to be valid but
> no-access) each representing 64K of nonexistent/invalid userland space.
>
You can, and that's the way the NetBSD/vax pmap works :-)
[ many ideas about moving around the process address space ]
>
> Of course, that juggle may come at a higher price than removing sbrk.
> That's a judgement call for you people to make. I just point out
> possibilities. :-)
>
Thanks, I have tried to move around things a bunch already, just for
test purposes (like letting all mmap() go in P1 space). The problem
is that it's just workarounds for the bad mmap/sbrk interaction.
-- Ragge