Locking a file backed mdconfig into memory

[Alan Cox]

On 6/4/2010 1:53 PM, John Baldwin wrote:
> On Friday 04 June 2010 1:58:13 pm Alan Cox wrote:
>    
>> Matthew D Fleming wrote:
>>      
>>> On Fri, Jun 04, 2010 at 08:20:49AM -0400, John Baldwin wrote:
>>>
>>>        
>>>> Hmmm, I would just try increasing NKPT then.  You might have to poke
>>>> around in sys/amd64 to see what the default size is and how to tune
>>>> it.
>>>>
>>>>          
>>> When Isilon did the stable/7 merge and amd64 default NKPT changed from
>>> 240 to 32 amd64 started having weird pmap issues during boot.  At panic
>>> time the stack wasn't very useful, and I didn't finish debugging the
>>> issue since eventually I just had to get something working.  We just
>>> reverted NKPT to 240 and it worked for us.  I didn't see an anything in
>>> optsions.amd64 so I hard-coded it in amd64/include/pmap.h.
>>>
>>> Supposedly amd64 can deal with a small NKPT and grow dynamically, but it
>>> didn't seem to work for us. :-( Perhaps when we do the next merge
>>> project I'll have a few days to devote to debugging the root cause.
>>>
>>>        
>> NKPT controls the number of page table pages that are initially
>> allocated at the bottom of the top 2GB of the kernel address space.
>> However, the vast majority of the kernel address space, 510GB in FreeBSD
>>   >=7.3, is below these page table pages.  The page table pages for this
>> region are dynamically allocated as needed.
>>
>> If you're booting a kernel and modules greater than 64GB in size, then I
>> can certainly see why you would need to increase NKPT.
>>      
> 64GB seems like a lot of address space, I would not expect that to be
> completely used by kernel and modules.  I think earlier in the thread someone
> said they had problems with a "mere" 295MB mfsroot.
>
>    

Oops.  I meant to say 64MB.  :-)

>> John, is there some way to know at boot time how big the kernel and
>> modules were?  Then, we could probably eliminate NKPT.
>>      
> I think the loader knows, so it could pass that info to the kernel.
>
>