This is the mail archive of the
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: Fri, 23 May 2014 01:26:35 -0400
- 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> <20140523031242 dot GA24355 at ubuntu> <20140523040146 dot GM507 at brightrain dot aerifal dot cx> <20140523042133 dot GA29872 at ubuntu> <20140523043129 dot GN507 at brightrain dot aerifal dot cx> <20140523043918 dot GA404 at ubuntu>
On Fri, May 23, 2014 at 12:39:18PM +0800, lin zuojian wrote:
> Hi Rich,
> > I'm aware of this, but is it dropped or not? First you claimed the
> > resident memory drops from the madvise call, but then you claimed it
> > doesn't drop from the page cache. I think you need to explain this
> > more clearly if there's going to be a discussion of the merits of your
> > proposal.
> It really drops the page tables, which alwarys belong to a process
> , not cache or other kernel usage.That would save some pages.
> But it does not drop from the page cache.
They are the same physical pages, so I don't see how you can drop one
without dropping the other.
> And the accoutable memory, e.g. RSS, of a process drops.
> The page reclaiming process will reclaim these pages earlier.
> Because it access eariler.
RSS is not "accountable memory". It's largely meaningless, because it
includes memory that can be dropped at any time (without a need to
save it to swap). Defining a process's memory usage in a meaningful
way is difficult, but dirty pages, commit charge, and total RW mapping
sizes are more likely to be useful metrics than RSS is.