Re: another approach to rss : sloppy rss

From: Christoph Lameter <clameter_at_sgi.com>
Date: 2004-11-20 06:21:38
On Fri, 19 Nov 2004, Nick Piggin wrote:

> Just coming back to your sloppy rss patch - this thing will of course allow
> unbounded error to build up. Well, it *will* be bounded by the actual RSS if
> we assume the races can only cause rss to be underestimated. However, such an
> assumption (I think it is a safe one?) also means that rss won't hover around
> the correct value, but tend to go increasingly downward.
>
> On your HPC codes that never reclaim memory, and don't do a lot of mapping /
> unmapping I guess this wouldn't matter... But a long running database or
> something?

Databases preallocate memory on startup and then manage memory themselves.
One reason for this patch is that these applications cause anonymous page
fault storms on startup given lots of memory which will make
the system seem to freeze for awhile.

It is rare for a program to actually free up memory.

Where this approach could be problematic is when the system is under
heavy swap load. Pages of an application will be repeatedly paged in and
out and therefore rss will be incremented and decremented. But in those
cases these incs and decs are not done in a way that is on purpose
parallel like in my test programs. So I would expect rss to be more
accurate than in my tests.

I think the sloppy rss approach is the right way to go.
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Nov 19 14:22:38 2004

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:32 EST