Date: Tue, 11 Oct 2011 11:12:42 -0500 From: Alan Cox <alc@rice.edu> To: Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> Cc: alc@freebsd.org, Kostik Belousov <kostikbel@gmail.com>, hackers@freebsd.org, Grzegorz Kulewski <grzegorz@kulewski.pl> Subject: Re: mmap performance and memory use Message-ID: <4E946AFA.6060105@rice.edu> In-Reply-To: <alpine.BSF.2.00.1110102325220.67653@wojtek.tensor.gdynia.pl> References: <alpine.BSF.2.00.1110061637270.15552@wojtek.tensor.gdynia.pl> <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <CAJUyCcMKZ1E5LoJ0BFZju_OH_jjDeqgvBMf8WZ%2BwDvJRFsbH6Q@mail.gmail.com> <alpine.BSF.2.00.1110071916190.8664@wojtek.tensor.gdynia.pl> <4E8FF4B8.7010300@rice.edu> <alpine.BSF.2.00.1110102325220.67653@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/10/2011 16:28, 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?
>
It is documented in mmap(2) on HEAD and 9.x:
MAP_PREFAULT_READ
Immediately update the calling process's
lowest-level
virtual address translation structures, such as its
page table, so that every memory resident page
within
the region is mapped for read access.
Ordinarily these
structures are updated lazily. The effect of this
option is to eliminate any soft faults that
would oth-
erwise occur on the initial read accesses to the
region. Although this option does not preclude prot
from including PROT_WRITE, it does not eliminate
soft
faults on the initial write accesses to the region.
I don't believe that this feature was merged into to 8.x. However,
there is no technical reason that it can't be merged.
>
> is it possible to force VM subsystem to operate on superpages when
> possible - i mean swapping in 2MB chunks?
>
Currently, no. For some applications, like the Sun/Oracle JVM, that
have code to explicitly manage large pages, there could be some benefit
in the form of reduced overhead. So, it's on my "to do" list, but no
where near the top of that list.
Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E946AFA.6060105>