At 09:32 AM 6/4/2001 +0100, Chris Gilbert wrote:
>On Monday 04 June 2001  5:44 am, Matt Thomas wrote:
> > Just like what I'm going with the PPC pmap, you might consider
> > using the section (1MB) PTEs to some or all of memory.
> > Considering the DNARD has a max of 64MB of RAM, sacrificing
> > 64MB of KVA to map that memory and then use PMAP_MAP_POOLPAGE
> > to map pools.
>
>Would be good to do, however currently the start of KVM is 0xf1000000,
>running using 80MB's on the acorn32, upto 112MB on footbridge based hardware.
>  If we wanted to do the above we need to first lower the start of the 
> kernel.
>  I'd actually suggest lowering it to 0xC000000 which gives us 768MB of extra
>kvm space.  It does mean that we need to implement the pmap_growkernel call.
>Having looked over the i386 version looks more to be a matter of knowing what
>active pmaps there are, i386 just has a list of them.  I'll look into getting
>growkernel implemented.  Then we have to start checking that bootloaders can
>cope with the change of address for the kernel.

More KVA space would be good.  The current PPC stuff has the same limitation
of 256MB of KVA space.

>Although perhaps we don't actually need to move the start of the kernel, and
>we just use 0xC0000000 - 0xefffffff as the kvm space, and shift
>PAGE_TABLE_SPACE_START up to 0xf10000000.   And then map the whole of
>0xc0000000 to 0xf0ffffff into user processes.  But that all seems a tad icky
>just to avoid having to boot from somewhere other than 0xf0000000.  I'll
>investigate booting from somewhere else in memory and do some test kernels.

Why can't we boot into 0xf1000000 and have reserve where the kernel is?

>First we really have to see if the bootloaders can cope.
>
> > For those systems with lots of RAM, use the same hook in UVM
> > that will be added to "cluster" page allocations to certain
> > memory regions.
>
>Any docs on this?  or is it an unimplemented thing at the moment?

Not yet.  Jason & I need to think out the interface.  It'd be nice to
make it applicable to other platforms which have mechanisms to address
a large amount of memory with a single TLB/PTE entries.  (should be faster
and cut down on TLB thrashing).
--
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message