Re: mmap performance and memory use
On Fri, Oct 28, 2011 at 7:38 AM, Alan Cox 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 feature. Svata ___ 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"
Re: mmap performance and memory use
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. 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? To force the allocation of the physical memory? Right now, the only way is for your program to touch the pages. 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. 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"
Re: mmap performance and memory use
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 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ 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"
Re: mmap performance and memory use
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@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: mmap performance and memory use
On 10/11/2011 12:36, Mark Tinguely wrote: On 10/11/2011 11:12 AM, Alan Cox wrote: On 10/10/2011 16:28, Wojciech Puchar wrote: 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 Am I correct in remembering that super-pages have to be aligned on the super-page boundary and be contiguous? Yes. However, if you allocate (or mmap(2)) a large range of virtual memory, e.g., 10 MB, and the start of that range is not aligned on a superpage boundary, the virtual memory system can still promote the four 2 MB sized superpages in the middle of that range. If so, in the mmap(), he may want to include the 'MAP_FIXED' flag with an address that is on a super-page boundary. Right now, the "VMFS_ALIGNED_SPACE" that does the VA super-page alignment is only used for device pagers. Yes. More precisely, the second, third, etc. mmap(2) should duplicate the alignment of the first mmap(2). In fact, this is what VMFS_ALIGNED_SPACE does. It looks at the alignment of the pages already allocated to the file (or vm object) and attempts to duplicate that alignment. Sooner or later, I will probably make VMFS_ALIGNED_SPACE the default for file types other than devices. Similarly, if the allocated physical pages for the object are not contiguous, then MAP_PREFAULT_READ will not result in a super-page promotion. As described in my earlier e-mail on this topic, in this case, I call these superpage mappings and not superpage promotions, because the virtual system creates a large page mapping, e.g., a 2 MB page table entry, from the start. It does not create small page mappings and then promote them to a large page mapping. 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"
Re: mmap performance and memory use
On 10/11/2011 11:12 AM, Alan Cox wrote: On 10/10/2011 16:28, Wojciech Puchar wrote: 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 Am I correct in remembering that super-pages have to be aligned on the super-page boundary and be contiguous? If so, in the mmap(), he may want to include the 'MAP_FIXED' flag with an address that is on a super-page boundary. Right now, the "VMFS_ALIGNED_SPACE" that does the VA super-page alignment is only used for device pagers. Similarly, if the allocated physical pages for the object are not contiguous, then MAP_PREFAULT_READ will not result in a super-page promotion. --Mark Tinguely ___ 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"
Re: mmap performance and memory use
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 ___ 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"
Re: mmap performance and memory use
On 07/10/2011 19:13, Alan Cox wrote: > On Thu, Oct 6, 2011 at 11:01 AM, Kostik Belousov wrote: >> For one thing, this indeed causes more memory use for the OS. This is >> somewhat mitigated by automatic use of superpages. Superpage promotion >> still keeps the 4KB page table around, so most savings from the >> superpages are due to more efficient use of TLB. >> >> > 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. But wouldn't the "conservative" superpages policy make it difficult in the OPs case to ever get promotions to superpages if he's touching pages almost randomly? > Similarly, mmap(..., MAP_PREFAULT_READ) on a large, memory resident file may > pre-map the file using superpage mappings. grep doesn't find this symbol in the sys src tree in 8-STABLE - nor it seems in /usr/include. But anyway, is there a mechanism which gives more guarantees than "may" (i.e. which forces this) - or if not, how hard would it be to add one? Some Linux-based "enterprise" software (including Java) use Linux-specific calls to allocate large pages directly. signature.asc Description: OpenPGP digital signature
Re: mmap performance and memory use
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? is it possible to force VM subsystem to operate on superpages when possible - i mean swapping in 2MB chunks? ___ 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"
Re: mmap performance and memory use
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
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"
Re: mmap performance and memory use
On Thu, Oct 6, 2011 at 11:01 AM, Kostik Belousov wrote: > On Thu, Oct 06, 2011 at 04:41:45PM +0200, Wojciech Puchar wrote: > > i have few questions. > > > > 1) suppose i map 1TB of address space as anonymous and touch just one > > page. how much memory is used to manage this? > I am not sure how deep the enumeration you want to know, but the first > approximation will be: > one struct vm_map_entry > one struct vm_object > one pv_entry > > Page table structures need four pages for directories and page table > proper. > > > > 2) suppose we have 1TB file on disk without holes and 10 processes > > mmaps this file to it's address space. are just pages shared or can > > pagetables be shared too? how much memory is used to manage such > > situation? > Only pages are shared. Pagetables are not. > > For one thing, this indeed causes more memory use for the OS. This is > somewhat mitigated by automatic use of superpages. Superpage promotion > still keeps the 4KB page table around, so most savings from the > superpages are due to more efficient use of TLB. > > 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. 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"
Re: mmap performance and memory use
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?
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
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.___
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"
Re: mmap performance and memory use
page. how much memory is used to manage this? I am not sure how deep the enumeration you want to know, but the first approximation will be: one struct vm_map_entry one struct vm_object one pv_entry actually i don't need precise answer but algorithms. Page table structures need four pages for directories and page table proper. 2) suppose we have 1TB file on disk without holes and 10 processes mmaps this file to it's address space. are just pages shared or can pagetables be shared too? how much memory is used to manage such situation? Only pages are shared. Pagetables are not. this is what i really asked, thank you for an answer. My example was rather extreme but datasets of tens of gigabytes would be used. superpages are due to more efficient use of TLB. actually this is not really working at least a while ago (but already in FreeBSD 8) i tested it. Even with 1GB squid process without any swapping it wasn't often allocating them. Even with working case it probably will not help much here unless completely all data is in RAM, and following explains why accurate tracking of the accesses and writes, which can result in better pageout performance. For the situation 1TB/10 processes, you will probably need to tune the amount of pv entries, see sysctl vm.pmap.pv*. so there is a workaround but causing lots of soft page faults as there would be no more than few hundreds or so instructions between touching different pages. What i want to do is database library (but no SQL!). It will be something alike (but definitely not the same and NOT compatible) CA-Clipper/Harbour or harbour but with higher performance and to use it including heavy cases. With this system one user is one process, one thread. if used as WWW/something alike it will be this+some other thing doing WWW interface but still one logged user=exactly one process As properly planned database tables should not be huge i assume most of them (possibly excluded parts that are mostly not used) will be kept in memory by VM subsystem. So hard faults and disk I/O will not be a deciding factor. To avoid system calls i just want to mmap tables and indexes. All semaphores can be done from userspace too, and i already know how to avoid lock contention well. Using indexes means doing lots of memory reads from different pages, but for every process it will be usually not all pages touched but small subset. So it MAY work well this way, or may end with 95% system CPU time mostly doing soft faults. But future question - is something for that case planned in FreeBSD? I think i am not the only one about that, not all people on earth use computers for few processes or personal usage and there are IMHO many cases when programs need to share huge dataset using mmap, while doing heavy timesharing. I understand that mmap works that way because it may be mapped in different places and even with parts of single file in different places as this is what mmap allows. But is it possible to make different mmap in kernel like that mmap_fullfile(fd,maxsize) which (taking amd64 case) will map file at 2MB boundary if maxsize<=2MB, 1GB boundary if maxsize<=1GB, 512GB boundary otherwise, with subsequent multiple 512GB address blocks if needed, and sharing everything? it is completely no problem that things like madvise from one process will clean madvise setting from other process, or other problems - as only one type of programs that are aware of this would use it. this way there will be practicaly no pagetable mapping overhead and actually simpler/faster OS duties. I don't really know how exactly VM subsystem works under FreeBSD but if it is not hard i may do this with some help from you. And no - i don't want to use any popular database systems for good reasons. ___ 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"
Re: mmap performance and memory use
On Thu, Oct 06, 2011 at 04:41:45PM +0200, Wojciech Puchar wrote: > i have few questions. > > 1) suppose i map 1TB of address space as anonymous and touch just one > page. how much memory is used to manage this? I am not sure how deep the enumeration you want to know, but the first approximation will be: one struct vm_map_entry one struct vm_object one pv_entry Page table structures need four pages for directories and page table proper. > > 2) suppose we have 1TB file on disk without holes and 10 processes > mmaps this file to it's address space. are just pages shared or can > pagetables be shared too? how much memory is used to manage such > situation? Only pages are shared. Pagetables are not. For one thing, this indeed causes more memory use for the OS. This is somewhat mitigated by automatic use of superpages. Superpage promotion still keeps the 4KB page table around, so most savings from the superpages are due to more efficient use of TLB. On the other hand, having non-shared page tables allows for much more accurate tracking of the accesses and writes, which can result in better pageout performance. For the situation 1TB/10 processes, you will probably need to tune the amount of pv entries, see sysctl vm.pmap.pv*. > > yes this is a real question - assume most of these processes are mostly > sleeping but every now and then do something and work of some set of > pages from this file and there is enough memory in computer to keep this > working set, but only if managing it by OS will not overuse memory. > ___ > 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" pgpokrQUSBSl6.pgp Description: PGP signature
mmap performance and memory use
i have few questions. 1) suppose i map 1TB of address space as anonymous and touch just one page. how much memory is used to manage this? 2) suppose we have 1TB file on disk without holes and 10 processes mmaps this file to it's address space. are just pages shared or can pagetables be shared too? how much memory is used to manage such situation? yes this is a real question - assume most of these processes are mostly sleeping but every now and then do something and work of some set of pages from this file and there is enough memory in computer to keep this working set, but only if managing it by OS will not overuse memory. ___ 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"
