On Tue, 17 Mar 2015 14:09:39 -0700 Shaohua Li <shli@xxxxxx> wrote: > There was a similar patch posted before, but it doesn't get merged. I'd like > to try again if there are more discussions. > http://marc.info/?l=linux-mm&m=141230769431688&w=2 > > mremap can be used to accelerate realloc. The problem is mremap will > punch a hole in original VMA, which makes specific memory allocator > unable to utilize it. Jemalloc is an example. It manages memory in 4M > chunks. mremap a range of the chunk will punch a hole, which other > mmap() syscall can fill into. The 4M chunk is then fragmented, jemalloc > can't handle it. Daniel's changelog had additional details regarding the userspace allocators' behaviour. It would be best to incorporate that into your changelog. Daniel also had microbenchmark testing results for glibc and jemalloc. Can you please do this? I'm not seeing any testing results for tcmalloc and I'm not seeing confirmation that this patch will be useful for tcmalloc. Has anyone tried it, or sought input from tcmalloc developers? > This patch adds a new flag for mremap. With it, mremap will not punch the > hole. page tables of original vma will be zapped in the same way, but > vma is still there. That is original vma will look like a vma without > pagefault. Behavior of new vma isn't changed. > > For private vma, accessing original vma will cause > page fault and just like the address of the vma has never been accessed. > So for anonymous, new page/zero page will be fault in. For file mapping, > new page will be allocated with file reading for cow, or pagefault will > use existing page cache. > > For shared vma, original and new vma will map to the same file. We can > optimize this without zaping original vma's page table in this case, but > this patch doesn't do it yet. > > Since with MREMAP_NOHOLE, original vma still exists. pagefault handler > for special vma might not able to handle pagefault for mremap'd area. > The patch doesn't allow vmas with VM_PFNMAP|VM_MIXEDMAP flags do NOHOLE > mremap. At some point (preferably an early point) we'd like a manpage update and a cc: to linux-man@xxxxxxxxxxxxxxx please. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
