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: lin zuojian <manjian2006 at gmail dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 23 May 2014 11:12:42 +0800
- Subject: Re: Propose to Use madvise API on Runtime Loader
- Authentication-results: sourceware.org; auth=none
- References: <20140523012855 dot GC14217 at ubuntu> <20140523025730 dot GL507 at brightrain dot aerifal dot cx>
Hi Rich,
On Thu, May 22, 2014 at 10:57:30PM -0400, Rich Felker wrote:
> 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.
>
I think you have not read my code carefully. My code means I want to
drop the pages & page tables from elf header to .rel.dyn, which is a
readonly region. My point is to drop these pages which is readonly
and clean and will not need after relocation.
> 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).
>
Definitely this will not happen. madvise_dontneed function doesn't
effect page cache. And according to the following code:
if (pte_young(ptent) &&
likely(!(vma->vm_flags & VM_SEQ_READ)))
mark_page_accessed(page);
it makes the page lives longer in the LRU. Active pages live longer.
> 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.
>
Again my code does not effect page caches. So I am not doing it
wrong right?
> Rich