mmap performance and memory use

[Svatopluk Kraus]

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.

To make SUPERPAGE mapping, it's obvious that all physical pages under
SUPERPAGE must be allocated in vm_object. And SUPERPAGE mapping must
be done before first access to them, otherwise a promotion is on the
way. MAP_PREFAULT_READ does nothing with it. If madvice() is used,
vm_object_madvise() is called but only cached pages are allocated in
advance. Of coarse, an allocation of all physical memory behind
virtual address space in advance is not preferred in most situations.

For example, I want to do some computation on 4M memory space (I know
that each byte will be accessed) and want to utilize SUPERPAGE mapping
without promotion, so save 4K page table (i386 machine). However,
malloc() leads to promotion, mmap() with MAP_PREFAULT_READ doesn't do
nothing so SUPERPAGE mapping is promoted, and madvice() with
MADV_WILLNEED calls vm_object_madvise() but because the pages are not
cached (how can be on anonymous memory), it is not work without
promotion too.

So, SUPERPAGE mapping without promotions is fine, but it can be done
only if physical memory being mapped is already allocated. Is it
really possible to force that in userland?

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.

   Svata

On Wed, Oct 26, 2011 at 1:35 AM, Alan Cox <alc at rice.edu> wrote:
> On 10/10/2011 4:28 PM, Wojciech Puchar wrote:
>>>
>>> Notice that vm.pmap.pde.promotions increased by 31.  This means that 31
>>> superpage mappings were created by promotion from small page mappings.
>>
>> thank you. i looked at .mappings as it seemed logical for me that is shows
>> total.
>>
>>> In contrast, vm.pmap.pde.mappings counts superpage mappings that are
>>> created directly and not by promotion from small page mappings.  For
>>> example, if a large executable, such as gcc, is resident in memory, the text
>>> segment will be pre-mapped using superpage mappings, avoiding soft fault and
>>> promotion overhead.  Similarly, mmap(..., MAP_PREFAULT_READ) on a large,
>>> memory resident file may pre-map the file using superpage mappings.
>>
>> your options are not described in mmap manpage nor madvise
>> (MAP_PREFAULT_READ).
>>
>> when can i find the up to date manpage or description?
>>
>
> A few minutes ago, I merged the changes to support and document
> MAP_PREFAULT_READ into 8-STABLE.  So, now it exists in HEAD, 9.0, and
> 8-STABLE.
>
> Alan
>
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>