From owner-freebsd-current@FreeBSD.ORG Mon Nov 29 15:32:21 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 280A8106564A; Mon, 29 Nov 2010 15:32:21 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id ECFC48FC17; Mon, 29 Nov 2010 15:32:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A608446B29; Mon, 29 Nov 2010 10:32:20 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C5198A029; Mon, 29 Nov 2010 10:32:19 -0500 (EST) From: John Baldwin To: Alan Cox Date: Mon, 29 Nov 2010 09:45:35 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <1290387926.16558.1283.camel@home-yahoo> <201011221447.13026.jhb@freebsd.org> <4CEB126E.2010509@rice.edu> In-Reply-To: <4CEB126E.2010509@rice.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201011290945.35128.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 29 Nov 2010 10:32:19 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: alc@freebsd.org, freebsd-current@freebsd.org, Sean Bruno Subject: Re: 40 vs 44 bit memory addressing HP DL580/980 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 15:32:21 -0000 On Monday, November 22, 2010 8:01:34 pm Alan Cox wrote: > On 11/22/2010 1:47 PM, John Baldwin wrote: > > On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote: > >> On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin wrote: > >> > >>> On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote: > >>>> Looks like these HP boxes have the capability to do 44 bit memory > >>>> addressing if configured to do so from the BIOS. > >>>> > >>>> Is anyone interested in any data from that setting? > >>> Does it boot ok? :) The MTRR code should handle that (there is a CPUID > >>> field that tells the OS how many bits are significant). Not sure if there > >>> are any places in the pmap that assume 40 bits, but a test boot is > >>> certainly > >>> worth trying. > >>> > >>> > >> Since we don't boot with 40-bit addressing, I can easily predict the > >> outcome. :-) > >> > >> The trouble with this machine is that the second 128GB of RAM is being > >> placed between 512G and 1T in the physical address space, which is beyond > >> the range of the (current) direct map. So, we take a page fault on the > >> first access to a page in the second 128GB through the direct map. > > Heh, I guess that is what your earlier patch did? Once that patch is applied > > I think Sean should just try 44-bit mode if so. > > > > Yes. > > If 44-bit addressing makes the placement of DRAM in the physical address > space any sparser, then we'll again have an insufficiently large direct > map. Also, I fear that we won't be able to allocate the vm_page_array > without enabling VM_PHYSSEG_SPARSE, which itself requires a change in > order to work. I believe someone has a change for that on amd64 already? -- John Baldwin