> The current pmap code uses the page tables set up by the prom.

Only marginally true: it does so for PROM-supplied "stuff" (the RPB
and when making various PROM calls).  Other than for those things, it
currently is _supposed_ to be using page tables solely of its
construction.

Some of this can change: the kernel can map the RPB on its own, and
probably should.  However, when you call PROM functions, you need to
be calling them with some sort of address space they're friendly to...


> It doesn't
> use address space identfiers,

yup.


> and the amount of kernel heap space is
> determined at pmap bootstrap time.

Yup.  Also, there's a large amount of unnecessarily-wired memory, and
the general way process address space is managed is completely wrong
for the Alpha in several different ways (the whole set of process page
tables don't have to be and shouldn't be mapped in the kernel, and
more of the user and kernel address spaces should be usable by the
system).


> This is all a problem, but it isn't
> necessarily a showstopper for just being able to deal with a very fat
> kernel, no?

for "very fat" == "total KV size <= 8G" no, none of those are
show-stoppers.  bump up maxusers and because of the bogus mapping
stuff currently in place because of user page tables, that 8G limit is
hit really quickly.  However, N megs of routing tables, or other
straightforward increases (e.g. tuning the number of kmem or mbuf
clusters) shouldn't cause a problem.



cgd