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: Rich Felker <dalias at aerifal dot cx>
- 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 14:15:11 -0400
- 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>
On Sun, Apr 14, 2013 at 11:12:22PM +0530, Siddhesh Poyarekar 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.
This is exactly what I was about to say. If you want the highest
performance malloc, you implement malloc as sbrk (plus storing the
size because realloc needs it) and free as nop. It's not impressive
for an allocator to perform better than glibc (but still much worse
than the fastest-possible one I just described) if it avoids returning
unused memory to the system....
Rich