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_at_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. AlanReceived on Tue Nov 23 2010 - 00:01:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC