<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On May 30, 2013, at 4:06 PM, Kurtis Martin wrote:</div><blockquote type="cite"><font size="1" face="Segoe UI">1) Why does jemalloc have smaps with such large Private_Clean size? I'm actually surprised jemalloc has such large smaps in general. I would expect a bunch of smaller smaps that match the configured chunk size.</font> <br></blockquote><div><br></div><div>I've been trying to figure this out for quite a while now, and I have yet to come up a way to transition pages that were mapped as MAP_PRIVATE|MAP_ANON to the Private_Clean state. My experiments included fork(2) abuse, mmap'ed files, shared anonymous memory, etc., and I'm currently out of ideas. If you're able to observe a process as its Private_Clean page count is increasing, can you capture an strace log to see what system calls are occurring? Also, can you tell me the Linux kernel version you're using, jemalloc configuration (e.g. whether munmap is disabled), and jemalloc run-time options specified?</div><div><br></div><div>Regarding large smaps, all the Unix operating systems I've dealt with coalesce mappings that have identical attributes. If jemalloc maps two chunks that happen to be adjacent to each other, the kernel tracks them as a single mapping. jemalloc goes to some effort to make coalescing possible, because Linux unfortunately does linear map scans that severely degrade performance if the number of map entries isn't kept low.</div><div><br></div><div>Thanks,</div><div>Jason</div></div><br></body></html>