From owner-freebsd-arch@FreeBSD.ORG Wed Aug 13 17:36:25 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B217106564A for ; Wed, 13 Aug 2008 17:36:25 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (ice.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id CAB088FC14 for ; Wed, 13 Aug 2008 17:36:24 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id EC46086CB1; Wed, 13 Aug 2008 12:36:23 -0500 (CDT) Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (ice.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 08558-02; Wed, 13 Aug 2008 12:36:23 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-165.icecube.wisc.edu [172.16.223.165]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 426D686B19; Wed, 13 Aug 2008 12:36:23 -0500 (CDT) Message-ID: <48A31B9A.6040705@freebsd.org> Date: Wed, 13 Aug 2008 19:36:26 +0200 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.16 (X11/20080804) MIME-Version: 1.0 To: John Baldwin References: <48981C19.8060009@freebsd.org> <200808051024.27043.jhb@freebsd.org> <48A2E62A.9060604@freebsd.org> <200808131214.43326.jhb@freebsd.org> In-Reply-To: <200808131214.43326.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at ice.icecube.wisc.edu Cc: freebsd-arch@freebsd.org Subject: Re: UMA MD Small Allocator Runtime Switching X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 17:36:25 -0000 John Baldwin wrote: > > [snipped bit about faking a direct map] >> I thought about it, but we can only use 4K pages on the G5 so this would >> put a large amount of pressure on the page table. IBM removed the block >> translation mechanism from the G5 and the CPU's superpage support is not >> available in the 32-bit compatibility mode under which we currently run. >> > > Hmm, I didn't know you weren't running in full 64-bit mode. Is that a > property of the G5 CPU that it only supports the 32-bit compat mode with > 64-bit extensions? > No, it supports full 64-bit mode as well, and likes that much better. In fact, you have to do a fair bit of work to keep it in the compatibility mode: it switches to the full 64-bit mode whenever it takes a trap, for instance. The initial porting target is the compatibility mode because (a) I'm lazy and didn't want to simultaneously do a brand new 64-bit port and deal with changes for the G5 and (b) it would be nice to have a single 32-bit PPC install CD that works on all machines with 32-bit operating system support. It's the trying to avoid any #ifdef G5 that creates this problem with the UMA allocator. I'm gotten this completely working using a bunch of dynamic switching stuff (I can boot multiuser and build world on both my G3 and G5 machine with the same kernel), but to do it I need to remove where it sets booted = 1 as an optimization when the MI UMA subsystem is initializing. -Nathan