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: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Sun, 14 Apr 2013 18:28:48 -0700
- Subject: Re: Question about madvise(DONTNEED) in glibc malloc
- References: <516ADB3C dot 9040805 at gmail dot com> <CAAHN_R2FK4Fj4u1hHJJ17fr2X_PJxDs+6h2azWbUzbZth2HdfQ at mail dot gmail dot com>
>> Performance counter stats for './ebizzy -S 3':
>>
>> 23919.162533 task-clock # 7.945 CPUs utilized
>> 2,533 context-switches # 0.106 K/sec
>> 77 CPU-migrations # 0.003 K/sec
>> 4,256 page-faults # 0.178 K/sec
>
> This doesn't prove that glibc use of MADV_DONTNEED is wrong. What
> this proves is that never giving memory back to the system results in
> crazy fast performance since we reduce syscall overhead. It doesn't
> justify never returning memory back to the system though.
One more. You know, "the light weight" syscall has two type. 1) most optimal
behavior when application's prediction is 100% correct. MADV_DONTNEED is this.
kernel doesn't have any heuritics, no add any additional lock. just drop pages
quickly. 2) most optimal behavior when application's prediction is 50-80% correct.
current vrange() proposal is this. kernel take an argument just as a hint. and
discard only when system meet memory starvation. of cource, this has side effect.
need some additional lock and then the peformance is worse then the prediction is
always correct.
An author posix_madvise() seems to know this Linux MADV_DONTNEED characteristic. but
malloc seems not to care so.
int
posix_madvise (void *addr, size_t len, int advice)
{
/* We have one problem: the kernel's MADV_DONTNEED does not
correspond to POSIX's POSIX_MADV_DONTNEED. The former simply
discards changes made to the memory without writing it back to
disk, if this would be necessary. The POSIX behavior does not
allow this. There is no functionality mapping the POSIX behavior
so far so we ignore that advice for now. */
if (advice == POSIX_MADV_DONTNEED)
return 0;