Re: Question about madvise(DONTNEED) in glibc malloc

[KOSAKI Motohiro <kosaki dot motohiro at 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;