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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
