Subject: Re: Enlarging KVM to 240Mb on EBSA/CATS/RPC's + possible speedups
To: Reinoud Zandijk <imago@kabel065011.kabel.utwente.nl>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: port-arm32
Date: 02/23/2001 13:19:51
On Friday 23 February 2001  1:01 pm, Reinoud Zandijk wrote:
> Dear all,
>
> i've been thinking about the following patch i would like to make for
> arm32 to allow KVM to be 256 Mb (max anyway to support OFW machines)....
>
> I would like to put all hardware device area's out of the KVM space and
> BEFORE the kernel-space i.e. before 0xf0000000. The KVM space would then
> grow from 0x5000000 (80Mb) to 0xe0000000 (240Mb)....

Note that there's also a chunk of memory allocated to the kernel that holds 
all the pt_entry_t data, see PAGE_TABLE_SPACE_START in 
sys/arch/arm32/include/vmparam.h

> Why one could ask ... well there were some complaints about the KVM space
> being too small and i noticed some oddities in the RPC/A7000 podule space
> code using level 2 page tables to map in parts of the potential huge
> podule memory space to save KVM (have to verify this ... but all signs
> point to that).
>
> In my opinion this isnt nessisary at all.... If we would map the podule
> space, MEMC, VIDC, Video memory and on EBSA/CATS machines the Footbridge
> below the kernel, we can easily use Section mappings wich are level 1 page
> descriptors of 1Mb instead of a layer of 2nd level page descriptors of
> 64kb/4kb. This will surely IMHO less trash the TLB and thus speedup the
> machines.

Be aware that the VRAM is mapped as 4k pages so that it looks the same for 
both DRAM and VRAM (shouldn't be that hard to tweak it to a section, and 
would speed up screen access as it's less tlb walking when using VRAM)

> Any idea's before i really go into this ? Any catches ? Who would like to
> try some test kernels for EBSA/CATS when i am ready for it ?

Are you sure this can be done?  All processes get the same mappings for 
0xf0000000, so currently they can all see the KVM (even if they can't 
actually access it, I presume it's a speedup for syscalls etc)  Doing this 
could cause potential breakage.

Is this an extension to the earlier work by Mikep and myself?  (I'd rather 
see that go in as it's smaller and then see the reworking afterwards, IE as 
it stands current still can't boot (actually it might do I've not tried since 
you commited the VIDC move)

Cheers,
Chris