Date: Tue, 8 Jun 2010 12:12:33 +0530 From: "C. Jayachandran" <c.jayachandran@gmail.com> To: Juli Mallett <jmallett@freebsd.org> Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips Message-ID: <AANLkTilddmkayyLoAuYLL2Ra8EVYoizlcQtb4vuHssSn@mail.gmail.com> In-Reply-To: <AANLkTikFRSBpwdqy-66CTk2rClt9NZvF-IFVe8NCj80y@mail.gmail.com> References: <AANLkTimIa3jmBPMhWIOcY6DenGpZ2ZYmqwDTWspVx0-u@mail.gmail.com> <AANLkTil2gE1niUWCHnsTlQvibhxBh7QYwD0TTWo0rj5c@mail.gmail.com> <AANLkTinA2D5iTDGPbflHVzLyAZW-ZewjJkUWWL8FVskr@mail.gmail.com> <4C07E07B.9060802@cs.rice.edu> <AANLkTimjyPc_AXKP1yaJaF1BN7CAGBeNikVzcp9OCb4P@mail.gmail.com> <4C09345F.9040300@cs.rice.edu> <AANLkTinmFOZY3OlaoKStxlNIRBt2G2I4ILkQ1P0CjozG@mail.gmail.com> <4C0D2BEA.6060103@cs.rice.edu> <AANLkTikZxx_30H9geHvZYkYd0sE-wiuZljEd0PAi14ca@mail.gmail.com> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <AANLkTilBxdXxXrWC1cAT0wX9ubmFrvaAdk4feG6PwDYQ@mail.gmail.com> <AANLkTimPm6A-nYG2AdNXeyA4ALnIVxEAJAUqPIDBN-T6@mail.gmail.com> <AANLkTilJm1RVd8TUZo55f9dU4ZeaC0UlShWHOn1AIdhD@mail.gmail.com> <AANLkTikFRSBpwdqy-66CTk2rClt9NZvF-IFVe8NCj80y@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 8, 2010 at 11:56 AM, Juli Mallett <jmallett@freebsd.org> wrote: > On Mon, Jun 7, 2010 at 23:13, C. Jayachandran <c.jayachandran@gmail.com> = wrote: >> On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett <jmallett@freebsd.org> wrot= e: >>> Do you intend to support o32 kernels in your port indefinitely? =A0I >>> 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. >>>=A0At 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. =A0(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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilddmkayyLoAuYLL2Ra8EVYoizlcQtb4vuHssSn>