This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Propose to Use madvise API on Runtime Loader
- From: Rich Felker <dalias at libc dot org>
- To: lin zuojian <manjian2006 at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 22 May 2014 22:57:30 -0400
- Subject: Re: Propose to Use madvise API on Runtime Loader
- Authentication-results: sourceware.org; auth=none
- References: <20140523012855 dot GC14217 at ubuntu>
On Fri, May 23, 2014 at 09:28:55AM +0800, lin zuojian wrote:
> Hi,
> I am trying to reduce the memory foot print of shared objects.After
> examine the layouts of many shared objects, I find out that the start
> part of a shared object will be seldom needed.
> So I add the following code to the runtime loader:
> madvice(si->base, si->rel + si->rel_count * 8, MADV_DONTNEED);
>
> And Find out the foot print drops proportionally dramatically.
> An very big shared object(libwebcore.so), drops from 7MB to 4MB.
> So I think it's a good idea to add this technique to the future
> eglibc.
>
> madvice tell *nix system to let go the page table and the page in
> the specify range. But not the vma.
As written this code is definitely not appropriate; it could even end
up applying MADV_DONTNEED to writable memory, which does not just
affect caching but actually obliterates any changes made to it (e.g.
relocations) and restores the mapping to the original on-disk state.
Another lesser problem is that it will tend to make loading the same
library by multiple processes much slower since each load will have to
go back to the disk (due to dumping the cache).
Basically requesting the kernel to drop caches is always wrong as a
default, and usually wrong even if you think you want to do so. It has
no bearing on how much memory is tied up, and just leads to suboptimal
use of memory. The kernel can choose much better what to keep cached
and what to drop than a naive rule like the one you proposed could do.
Rich