Subject: Re: Section PTEs
To: Chris Gilbert <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 06/04/2001 10:50:58
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
> 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: email@example.com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message