svn commit: r208589 - head/sys/mips/mips

[C. Jayachandran]

On Tue, Jun 8, 2010 at 11:56 AM, Juli Mallett <jmallett at freebsd.org> wrote:
> On Mon, Jun 7, 2010 at 23:13, C. Jayachandran <c.jayachandran at gmail.com> wrote:
>> On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett <jmallett at freebsd.org> wrote:
>>> Do you intend to support o32 kernels in your port indefinitely?  I
>>> wonder whether this work is just stopgap until the systems which have
>>> large amounts of RAM can just use n64 kernels.
>>
>> I think the page table work will be needed for o32 and n32, and I
>> would like to support one of them as the preferred 32bit mode for our
>> port.
>
> OK.
>
>> BTW, n32 with >4GB RAM can be supported with XKPHYS for page table
>> entries. The options there would be either special allocator for the
>> segtab (11+9+12 addr space split), or to use special allocator for all
>> the page table pages (10+10+12 split).
>
> Yeah, but we have a disinterest in supporting n32 kernels in base
> because it breaks assumptions in so many parts of the kernel, so I
> think the most reasonable expectation for base is to support o32 and
> n64, and to strongly prefer n64 for systems where it's more
> appropriate.

I've been maintaining a version of n32 kernel (completely based on  on
your patches) against CURRENT, which boots into multi-user.  I would
like to compare the performance with n64 before ruling it out fully.

>>> At least on Octeon it
>>> seems to me that n64-only is the right answer if at all possible,
>>> since there are really a lot of parts of the kernel that just can't
>>> reasonably work otherwise (use of rman_get_virtual with io ports, for
>>> instance.)
>>
>> Not sure I understand this part - I thought pmap_mapdev() would handle
>> these - but I may be mistaken.
>
> There's nothing pmap_mapdev can do on an o32 kernel with 32-bit PTEs
> for a physical address >2^36.  (There are rather a lot of those on
> Octeon.)

In XLR the boot-loader sets up the base registers to fall within 2^32.
 It even sets up some of the SoC, FLASH and PCI memory areas in KSEG0,
so we end up with 256MB usable in KSEG0.  These can be easily
re-mapped, but I'd rather not change the boot loader settings just for
FreeBSD.

JC.