This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Question about madvise(DONTNEED) in glibc malloc
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: libc-alpha at sourceware dot org
- Cc: kosaki dot motohiro at gmail dot com
- Date: Sun, 14 Apr 2013 22:01:52 -0700
- Subject: Re: Question about madvise(DONTNEED) in glibc malloc
- References: <516ADB3C dot 9040805 at gmail dot com> <20130415042809 dot GT20323 at brightrain dot aerifal dot cx>
(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.