large pages (amd64)

[Alan Cox]

Mel Flynn wrote:
> On Sunday 28 June 2009 15:41:49 Alan Cox wrote:
>   
>> Wojciech Puchar wrote:
>>     
>
>   
>>> how can i check how much (or maybe - what processes) 2MB pages are
>>> actually allocated?
>>>       
>> I'm afraid that you can't with great precision.  For a given program
>> execution, on an otherwise idle machine, you can only estimate the
>> number by looking at the change in the quantity "promotions + mappings -
>> demotions" before, during, and after the program execution.
>>
>> A program can call mincore(2) in order to determine if a virtual address
>> is part of a 2 or 4MB virtual page.
>>     
>
> Would it be possible to expose the super page count as kve_super in the 
> kinfo_vmentry struct so that procstat can show this information? If only to 
> determine if one is using the feature and possibly benefiting from it.
>
>   

Yes, I think so. 

> It looks like sys/kern/kern_proc.c could call mincore around the loop at line 
> 1601 (rev 194498), but I know nothing about the vm subsystem to know the 
> implications or locking involved. There's still 16 bytes of spare to consume, 
> in the kve_vminfo struct though ;)
>   

Yes, to start with, you could replace the call to pmap_extract() with a 
call to pmap_mincore() and export a Boolean to user space that says, 
"This region of the address space contains one or more superpage mappings."

Counting the number of superpages is a little trickier.  The problem 
being that pmap_mincore() doesn't tell you how large the underlying page 
is.  So, the loop at line 1601 can't easily tell where one superpage 
ends and the next 4KB page or superpage begins, making counting the 
number of superpages in a region a little tricky.  One possibility is to 
change pmap_mincore() to return the page size (or the logarithm of the 
page size) rather than a single bit.

If you want to give it a try, I'll be happy to help.  There aren't 
really any "implications" or synchronization issues that you need to 
worry about.

Alan