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 <a...@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@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"
