Subject: Re: Enlarging KVM to 240Mb on EBSA/CATS/RPC's + possible speedups
To: Chris Gilbert <chris@paradox.demon.co.uk>
From: Reinoud Zandijk <imago@kabel065011.kabel.utwente.nl>
List: port-arm32
Date: 02/23/2001 14:42:03
Hi Chris,
On Fri, 23 Feb 2001, Chris Gilbert wrote:
> 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
Yep :)) I noticed it ... it sits JUST before 0xf0000000 ... allready
wondered why it was there but oh well :) better not map yourself in and
then change mappings in mapped memory (euhm... am i losing my mind :)) )
> 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)
Nope ... since the new bootloader its mapped as one or two sections of 1
MB.... this is prolly why the screen is much faster on my machine now
anyway. Thats also the reason why I allways claim the maximum 1Mb for
screen memory when there is no VRAM ... or claim the 2Mb VRAM for video
only. Thats why i removed the option to choose the amount of DRAM used.
> > 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.
This 0xf0000000 boundary is set on two places... one that describes the
boundaries of user virtual memory space and kernel virtual memory space
and one that signals the start of the kernel.... i only want to change the
first ! ... so that the pte's go before that ... (wierd construction ...
but oh well).
> 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)
Well honestsly i've not really started on it as yet and i was planning to
do it on my VIDC mode patch.... well that will be moved again anyway....
the new bootloader isnt picky on where you map things when the kernel
starts.... it may do what it likes :)
My VIDC move grows the KVM to 80Mb from 40? or so ....
If this new plan fails then sure why not try your and MikeP's patches...
if they still work OK, then why not? Thanks again for your work BTW :)
Euhm... only what's "IE" ?
Cheers,
Reinoud