mmap performance and memory use

Svatopluk Kraus onwahe at
Mon Oct 31 12:59:32 UTC 2011

On Fri, Oct 28, 2011 at 7:38 AM, Alan Cox <alc at> wrote:
> On 10/26/2011 06:23, Svatopluk Kraus wrote:
>> Hi,
>> well, I'm working on new port (arm11 mpcore) and pmap_enter_object()
>> is what I'm debugging rigth now. And I did not find any way in
>> userland how to force kernel to call pmap_enter_object() which makes
>> SUPERPAGE mapping without promotion. I tried to call mmap() with
>> MAP_PREFAULT_READ without success. I tried to call madvise() with
>> MADV_WILLNEED without success too.
> mmap() should call pmap_enter_object() if MAP_PREFAULT_READ was specified.
>  I'm surprised to hear that it's not happening for you.

Yes, it's not happening for me really.

mmap() with MAP_PREFAULT_READ case:
vm_mmap() in sys/vm/vm_mmap.c (r225617)
line 1501 - if MAP_ANON then docow = 0
line 1525 - vm_map_find() is called with zeroed docow

It's propagated down the calling stack, so even vm_map_pmap_enter() is
not called in vm_map_insert(). Most likely, this is correct.
(Anonymous object -> no physical memory allocation in advance -> no
SUPERPAGE mapping without promotion.)

madvise() with MADV_WILLNEED case:
vm_map_pmap_enter() in sys/vm/vm_map.c (r223825)
line 1814 - vm_page_find_least() is called

During madvise(),  vm_map_pmap_enter() is called. However, in the
call, vm_page_find_least() returns NULL. It returns NULL, if no page
is allocated in object with pindex greater or equal to the parameter
pindex. The following loop after the call says that if no page is
allocated for SUPERPAGE (i.e. for given region), pmap_enter_object()
is not called and this is correct.


>> Moreover, the SUPERPAGE mapping is made readonly firstly. So, even if
>> I have SUPERPAGE mapping without promotion, the mapping is demoted
>> after first write, and promoted again after all underlying pages are
>> accessed by write. There is 4K page table saving no longer.
> Yes, that is all true.  It is possible to change things so that the page
> table pages are reclaimed after a time, and not kept around indefinitely.
>  However, this not high on my personal priority list.  Before that, it is
> more likely that I will add an option to avoid the demotion on write, if we
> don't have to copy the entire superpage to do so.

Well, I just wanted to remark that there is no 4K page table saving
now. However, there is still big TLB entries saving with SUPERPAGE
promotions. I'm not pushing you to do anything.

I understand that physical pages allocation in advance is not good
idea and it goes against great copy on write feature. However,
something like MAP_PREFAULT_WRITE on MAP_ANON, which allocates all
physical pages in advance and does SUPERPAGE mapping without promotion
sounds like a good-but-really-specific feature, which can be utilized
sometimes. Nevertheless, IMHO, it's not worth to do such specific


More information about the freebsd-hackers mailing list