Hello Jason, On Fri, Jan 31, 2014 at 01:44:55AM +0000, Jason Evans wrote: > On 1/30/14, 5:27 PM, "John Stultz" <john.stultz@xxxxxxxxxx> wrote: > >I'm still not totally sure about, but willing to try > >* Page granular volatile tracking > > In the malloc case (anonymous unused dirty memory), this would have very > similar characteristics to madvise(...MADV_FREE) as on e.g. FreeBSD, but > with the extra requirement that memory be marked nonvolatile prior to > reuse. That wouldn't be terrible -- certainly an improvement over > madvise(...MADV_DONTNEED), but range-based volatile regions would actually > be an improvement over prior art, rather than a more cumbersome equivalent. > > Either way, I'm really looking forward to being able to utilize volatile > ranges in jemalloc. First of all, Again, I should thank for your help! While I discuss with Johannes, I'm biasing to implemnt MADV_FREE for Linux. instead of vrange syscall for allocator. The reason I preferred vrange syscall over MADV_FREE is vrange syscall is almost O(1) so it's really light weight system call although it needs one more syscall to unmark volatility while MADV_FREE is O(#pages) but as Johannes pointed out, these day kernel trends are using huge pages(ex, 2M) so I guess the overhead is really big. (Another topic: If application want to use huge pages on Linux, it should mmap the region is aligned to the huge page size but when I read jemalloc source code, it seems not. Do you have any reason?) As a bonus point, many allocators already has a logic to use MADV_FREE so it's really easy to use it if Linux start to support it. Do you see other point that light-weight vrange syscall is superior to MADV_FREE of big chunk all at once? Thanks for the comment, Jason. > > Thanks, > Jason > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a> -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>