Re: [PATCH v10 00/16] Volatile Ranges v10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]