From owner-freebsd-ppc@FreeBSD.ORG Tue Oct 21 22:20:00 2008 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC5D310656A0; Tue, 21 Oct 2008 22:20:00 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 82EDD8FC14; Tue, 21 Oct 2008 22:20:00 +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 BF19858244; Tue, 21 Oct 2008 17:19:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z58qGTUZkcwx; Tue, 21 Oct 2008 17:19:59 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-55-165.icecube.wisc.edu [172.16.55.165]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 0D64758243; Tue, 21 Oct 2008 17:19:58 -0500 (CDT) Message-ID: <48FE557C.5020207@freebsd.org> Date: Tue, 21 Oct 2008 17:19:40 -0500 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.17 (X11/20081002) MIME-Version: 1.0 To: Peter Grehan References: <20081022050101.EKN14563@dommail.onthenet.com.au> In-Reply-To: <20081022050101.EKN14563@dommail.onthenet.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: graphics on G4 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2008 22:20:00 -0000 Peter Grehan wrote: > Hi Justin, > > >>> The framebuffer uses a large chunk of kernel VM when mmap'd. >>> Are you able to dump some vm stats while doing this e.g. >>> sysctl vm.kvm_free ? >>> > > I shouldn't hit send before the morning coffee :( mmap'ing > uses process VM, not kernel, except for the extra alloc's > needed for this but these should all come from the non-KVA UMA > small malloc area. > One thing that worries me about our PMAP layer could cause this. This machine has a lot of RAM. What happens if we have physical or device memory in the same range as kmem VAs? It seems like trying to modify it through the BAT map (as zero/copy page, /dev/mem and friends do) will overwrite random bits of KVA instead... -Nathan