Date: Sat, 08 Oct 2011 01:59:04 -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: <4E8FF4B8.7010300@rice.edu> In-Reply-To: <alpine.BSF.2.00.1110071916190.8664@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/07/2011 12:23, Wojciech Puchar wrote:
>>
>> You are correct about the page table page. However, a superpage
>> mapping consumes a single PV entry, in place of 512 or 1024 PV
>> entries. This winds up saving about three physical pages worth of
>> memory for every superpage mapping.
> does it actually work?
>
Yes, the sysctl output shows that it is working. You can also verify
this with mincore(2).
> simple test
>
> before (only idle system with 2GB RAM and most free)
>
> vm.pmap.pde.promotions: 921
> vm.pmap.pde.p_failures: 21398
> vm.pmap.pde.mappings: 299
> vm.pmap.pde.demotions: 596
> vm.pmap.shpgperproc: 200
> vm.pmap.pv_entry_max: 696561
> vm.pmap.pg_ps_enabled: 1
> vm.pmap.pat_works: 1
>
>
> and with that program running (==sleeping)
>
> #include <unistd.h>
> int a[1<<24];
> main() {
> int b;
> for(b=0;b<(1<<24);b++) a[b]=b;
> sleep(1000);
> }
>
>
> vm.pmap.pdpe.demotions: 0
> vm.pmap.pde.promotions: 952
> vm.pmap.pde.p_failures: 21398
> vm.pmap.pde.mappings: 299
> vm.pmap.pde.demotions: 596
> vm.pmap.shpgperproc: 200
> vm.pmap.pv_entry_max: 696561
> vm.pmap.pg_ps_enabled: 1
> vm.pmap.pat_works: 1
>
>
>
> seems like i don't understand what these sysctl things mean (i did
> sysctl -d)
> or it doesn't really work. with program allocating and using linear
> 64MB chunk it should be 31 or 32 more mappings in vm.pmap.pde.mappings
> there are zero difference.
Notice that vm.pmap.pde.promotions increased by 31. This means that 31
superpage mappings were created by promotion from small page mappings.
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.
Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E8FF4B8.7010300>