On Wed, Jan 2, 2013 at 8:27 PM, Minchan Kim <minc...@kernel.org> wrote: > This is still RFC because we need more input from user-space > people, more stress test, design discussion about interface/reclaim
Speaking as one of the authors of tcmalloc, I don't see any particular need for this new system call for tcmalloc. We are fine using madvise(MADV_DONTNEED) and don't notice any significant performance issues caused by it. Background: we throttle how quickly we release memory back to the system (1-10MB/s), so we do not call madvise() very much, and we don't end up reusing madvise-ed away pages at a fast rate. My guess is that we won't see large enough application-level performance improvements to cause us to change tcmalloc to use this system call. > - What's different with madvise(DONTNEED)? > > System call semantic > > DONTNEED makes sure user always can see zero-fill pages after > he calls madvise while mvolatile can see old data or encounter > SIGBUS. Do you need a new system call for this? Why not just a new flag to madvise with weaker guarantees than zero-filling? All of the implementation changes you point out below could be triggered from that flag. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/