Date: Mon, 29 Nov 2010 09:45:35 -0500 From: John Baldwin <jhb@freebsd.org> To: Alan Cox <alc@rice.edu> Cc: alc@freebsd.org, freebsd-current@freebsd.org, Sean Bruno <seanbru@yahoo-inc.com> Subject: Re: 40 vs 44 bit memory addressing HP DL580/980 Message-ID: <201011290945.35128.jhb@freebsd.org> In-Reply-To: <4CEB126E.2010509@rice.edu> References: <1290387926.16558.1283.camel@home-yahoo> <201011221447.13026.jhb@freebsd.org> <4CEB126E.2010509@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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<jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011290945.35128.jhb>