On Sep 23, 2013, at 9:59 AM, bill <[email protected]> wrote: > I've noticed that an allocation request for a large chunk of memory (128GB) > results in two calls to pages_map() (in src/chunk_mmap.c), consuming 2x the > VM I requested. In a 64 bit world this is not a big problem, but I've > recoded pages_map() to force allocation from an mmap'd ssd (instead of swap > anonymous mmap), and it's forcing me to run out of backing store. The issue > I would like to understand is why pages_map() is called twice with separate > requests for the single 128GB jemalloc() that I'm doing in my application. > The first allocation is followed by a call to pages_unmap(), but with an > unmap size of 0 bytes, leaving it fully mapped, while the second allocation > (which is slightly larger than 128GB) is trimmed to exactly 128GB by 2 > subsequent pages_unmap() calls. This behavior seems very strange to me, and > any explanation would be appreciated.
It sounds like the first time pages_map() is called, it returns a result that isn't adequately aligned. The second time, extra space is allocated so that the result can be trimmed to alignment boundaries. You say that the interposed call to pages_unmap() receives a size of 0. Assuming the call is coming from chunk_alloc_mmap(), I see no way that can happen. There was a bug in a ~3-year-old version of jemalloc of this nature, but I hope you're using a more modern version. Also of relevance: the SSD backing feature you added existed in 2.x versions of jemalloc, but I removed it because no one ever claimed to have found it useful. Jason _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
