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: OndÅej BÃlka <neleai at seznam dot cz>
- To: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 15 Apr 2013 12:09:25 +0200
- 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> <516B57D0 dot 1000600 at gmail dot com>
On Sun, Apr 14, 2013 at 06:28:48PM -0700, KOSAKI Motohiro wrote:
> >> 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.
>
Dropping pages is not optimal behaviour. You can get better by reusing
them.
> An author posix_madvise() seems to know this Linux MADV_DONTNEED characteristic. but
> malloc seems not to care so.
>
Author cares about writing file changes. Malloc do not handle any files.
>
> 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;