Date: Tue, 8 Jun 2010 11:43:53 +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: <AANLkTilJm1RVd8TUZo55f9dU4ZeaC0UlShWHOn1AIdhD@mail.gmail.com> In-Reply-To: <AANLkTimPm6A-nYG2AdNXeyA4ALnIVxEAJAUqPIDBN-T6@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett <jmallett@freebsd.org> wrote: > Hey JC, > > On Mon, Jun 7, 2010 at 21:07, C. Jayachandran <c.jayachandran@gmail.com> = wrote: >> Yes. I saw the PAE top level page table code and thought I could use >> that mechanism for allocating MIPS page table pages in the direct >> mapped memory. The other reference I used was >> pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which >> uses the vm_phys_alloc_contig() and VM_WAIT. =A0I had also thought of >> using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose, >> but could find see any usage in the kernel. > > 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. 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). >=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. JC.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilJm1RVd8TUZo55f9dU4ZeaC0UlShWHOn1AIdhD>