From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 04:14:03 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2974C106564A for ; Tue, 8 Jun 2010 04:14:03 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01EA98FC16 for ; Tue, 8 Jun 2010 04:14:02 +0000 (UTC) Received: by pwj1 with SMTP id 1so2257032pwj.13 for ; Mon, 07 Jun 2010 21:14:02 -0700 (PDT) Received: by 10.114.165.18 with SMTP id n18mr12429011wae.3.1275970442259; Mon, 07 Jun 2010 21:14:02 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.114.241.2 with HTTP; Mon, 7 Jun 2010 21:13:42 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> From: Juli Mallett Date: Mon, 7 Jun 2010 21:13:42 -0700 X-Google-Sender-Auth: BEFZU6i7mf27n3bQxP8LG9zig28 Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 04:14:03 -0000 Hey JC, On Mon, Jun 7, 2010 at 21:07, C. Jayachandran wr= ote: > 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? I wonder whether this work is just stopgap until the systems which have large amounts of RAM can just use n64 kernels. 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.) Thanks, Juli.