HEADS UP: MIPS switching to common pmap (uvm/pmap)

[Matt Thomas]

I now have MIPS using the same pmap code as PowerPC BookE in sys/uvm/pmap.

I plan on merging it into the tree next week. I’ve tested it on ERLITE, MALTA, and TWRP1025 but I’m sure there are going to some issues.

If you have a MIPS system and you’d like to try a new kernel, let me know and I can built you one.

For those using 64-bit CPUs, using N32 for the kernel will give a decided performance boost. N32 kernels run with a full 64-bit address. bus_space, the cache routines, and the page zero and copy routines have been updated to take and use 64-bit direct mapped addresses whenever possible. This means the N32 kernels can use more memory than fits in KSEG0.

For MIPS3+ and MIPSNN, the default page size has been changed to 8KB which speeds the kernel. The locore routines for mips3 have been updated to use mipsNNr2 instructions to increase speed.

By using the common pmap code, MIPS kernel now support dynamically increasing kernel address space.



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de

[Matt Thomas]

> On Jun 25, 2015, at 6:42 PM, Simon Burge <sim...@NetBSD.org> wrote:
>
> Hi Matt,

>
> Matt Thomas wrote:
>
>> I now have MIPS using the same pmap code as PowerPC BookE in
>> sys/uvm/pmap.
>>
>> I plan on merging it into the tree next week.
>>

>> [ ... ]

>>
>> By using the common pmap code, MIPS kernel now support dynamically
>> increasing kernel address space.
>

> Have you benchmarked the new common pmap? I'm curious if it's better,
> worse or the the same for any micro benchmarks that are pmap dependant
> (lmbench fork comes to mind, maybe something with lots of malloc/free?).

I’ve been trying to get it to work. My kernels have DEBUG/DIAGNOSTIC
enabled so I haven’t been testing performance. For MIPS3+ 32-bit kernels,
both kernel and user address are both handled by the TLB miss handler.
With 8KB pages, we only need to load one PTE. It does feel faster. There’s
no more kern_tlb_invalidate since either both halves of the TLB entry are
valid or neither are. A lot of kernel-specific code has gone away now that
the kernel uses standard pmap PTE lookups.

>> If you have a MIPS system and you'd like to try a new kernel,
>> let me know and I can built you one.
>

> If there's anything you think needs testing that you don't have access
> to, let me know. I've still got way too much crap in the garage :).

r5k are my bane.

[Simon Burge]

Hi Matt,

Matt Thomas wrote:

> I now have MIPS using the same pmap code as PowerPC BookE in
> sys/uvm/pmap.
>
> I plan on merging it into the tree next week.
>

> [ ... ]

>
> By using the common pmap code, MIPS kernel now support dynamically
> increasing kernel address space.

Have you benchmarked the new common pmap? I'm curious if it's better,
worse or the the same for any micro benchmarks that are pmap dependant
(lmbench fork comes to mind, maybe something with lots of malloc/free?).

> If you have a MIPS system and you'd like to try a new kernel,
> let me know and I can built you one.

If there's anything you think needs testing that you don't have access
to, let me know. I've still got way too much crap in the garage :).

Cheers,
Simon.