Date: Mon, 31 Oct 2011 13:59:31 +0100 From: Svatopluk Kraus <onwahe@gmail.com> To: Alan Cox <alc@rice.edu> Cc: alc@freebsd.org, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl>, Kostik Belousov <kostikbel@gmail.com>, hackers@freebsd.org, Grzegorz Kulewski <grzegorz@kulewski.pl> Subject: Re: mmap performance and memory use Message-ID: <CAFHCsPXarBBQ=Py8Ns9VR2t5m5vWZ0OOZCPPu1%2BJSQS100p4mg@mail.gmail.com> In-Reply-To: <4EAA3FBC.3090907@rice.edu> 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> <4EA747B5.9040304@rice.edu> <CAFHCsPXb4Z0NP49OFRttwaAeagE_JV0-QYTTTUzimV7MVfxXFg@mail.gmail.com> <4EAA3FBC.3090907@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 28, 2011 at 7:38 AM, Alan Cox <alc@rice.edu> 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= . > =A0I'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 =3D 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. <snip> >> 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. =A0It is possible to change things so that the pag= e > table pages are reclaimed after a time, and not kept around indefinitely. > =A0However, this not high on my personal priority list. =A0Before that, i= t 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPXarBBQ=Py8Ns9VR2t5m5vWZ0OOZCPPu1%2BJSQS100p4mg>