Re: Question about madvise(DONTNEED) in glibc malloc

[OndÅej BÃlka <neleai at seznam dot cz>]

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;