40 vs 44 bit memory addressing HP DL580/980

[Alan Cox]

John Baldwin wrote:
> 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 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.
>>     
>
> I believe someone has a change for that on amd64 already?
>
>   

Yes.

Alan