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: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 15 Apr 2013 07:09:38 -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> <516B57D0 dot 1000600 at gmail dot com> <20130415100925 dot GA6228 at domone dot kolej dot mff dot cuni dot cz>
(4/15/13 3:09 AM), OndÅej BÃlka wrote:
> 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.
Sorry, I can't understand what you tried say. Have you take a look current DONTNEED implementation?