This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about madvise(DONTNEED) in glibc malloc


(4/14/13 9:28 PM), Rich Felker wrote:
> On Sun, Apr 14, 2013 at 09:37:16AM -0700, KOSAKI Motohiro wrote:
>> Hi all,
>>
>> Now, we linux MM folks discuss are discussing about new memory
>> discarding feature. (https://lkml.org/lkml/2013/3/12/105). The
>> motivation is similar wtih MADV_FREE, but more efficient.
>> (http://lwn.net/Articles/230799)
> 
> If you're following this, do you know if vrange(VRANGE_NOVOLATILE) has
> failure cases? 

If any pages have already been discarded, vrange(VRANGE_NOVOLATILE) return 1.
Subsequent memory access may cause minor page fault and makes page zero fill.


> This makes a big difference to how usable it is by
> malloc implementations. madvise re-mmapping new zero pages over the
> range are nice in that the range is not using physical memory, but
> still remains committed and immediately usable without any risk of
> failure to get it back. 

Does you "commit" mean to talk about virtual address? If yes, vrange() never
call neither mmap/munmap implicitly.
If you are talk about physical pages, it may be discarded and disappeared. vrange()
user must not pass undroppable data.

> If vrange can fail to "get back" the range,
> this makes it a lot harder to use robustly.

Any linux syscall _can_ return ENOMEM if system has really no memory.
but we've never seen practically because kernel handle memory starvation enough
clever.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]