From owner-freebsd-mips@FreeBSD.ORG Tue Jun 8 06:42:35 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 809B71065675; Tue, 8 Jun 2010 06:42:35 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 10E128FC08; Tue, 8 Jun 2010 06:42:34 +0000 (UTC) Received: by vws4 with SMTP id 4so3253413vws.13 for ; Mon, 07 Jun 2010 23:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2ce52xBgRmc9cKitnuJFIAcncEpdaUJX4pmgs/VN9Ns=; b=VNPaieL4KiMoxcQf/YFb9sev4mD1JxgGmLvW+jMSrgKMDtgtNDfaBdD1haGEI9fnDQ qPtKNPhiHGTJWERR7K7rsmWOsAXDTwCmHO2tyoeqXCPXZPSTHFMxhKvHg0y1Ud+H5V0W WCDPK9nmJL/pEJv1KjZ2XKIhoINV/7oYH/seA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eL1iBrdokZXDMWaxcQD/CfWKH7NUAC9F+vNMdG22prIO8WSGuRMz3DCW6obGl41OWs mHzuMNioSJwl3G2s/E60ouCcAYDv/ikEFJW91jlET6/BoRvsmKe/6zURQUUhT+vIuiBX jPJf4JGQOQAiDPBqW0s9a0rAFkHVAI7BLPS2g= MIME-Version: 1.0 Received: by 10.229.234.3 with SMTP id ka3mr3027702qcb.261.1275979354006; Mon, 07 Jun 2010 23:42:34 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Mon, 7 Jun 2010 23:42:33 -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> Date: Tue, 8 Jun 2010 12:12:33 +0530 Message-ID: From: "C. Jayachandran" To: Juli Mallett 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 06:42:35 -0000 On Tue, Jun 8, 2010 at 11:56 AM, Juli Mallett wrote: > On Mon, Jun 7, 2010 at 23:13, C. Jayachandran = wrote: >> On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett 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.