Re: RSS Limit implementation issue

From: Bill Davidsen
Date: Thu Mar 30 2006 - 15:24:48 EST


Ram Gupta wrote:
On 2/9/06, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
On Iau, 2006-02-09 at 15:10 -0600, Ram Gupta wrote:
I am working to implement enforcing RSS limits of a process. I am
planning to make a check for rss limit when setting up pte. If the
limit is crossed I see couple of different ways of handling .

1. Kill the process . In this case there is no swapping problem.
Not good as the process isn't responsible for the RSS size so it would
be rather random.


I doubt I am missing some point here. I dont understand why the
process isn't responsible for RSS size. This limit is process specific
& the count of rss increases when the process maps some page in its
page table.

A process has no control over its RSS size, only its virtual size. I'm not sure you're clear on that, or just not saying it clearly. Therefore the same process, say a largish perl run, may be 175mB in vsize, and during the day have rss of perhaps half that. At night, with next to no load on the machine, the rss is 175mB because there is a bunch of free memory available.

If you want to make rss a hard limit the result should be swapping, not failure to run. I'm not sure the limit in that form is a good idea, and before someone reminds me, I do remember liking it better a few years ago.

If you can come up with a better way to adjust rss to get better overall greater throughput while being fair to all processes, go to it. But in general these things are a tradeoff, like swappiness, you tune until the volume of complaints reaches a minimum.

You could do tuning to get minimum page faults overall, or assure a minumum size, or... I think there's room for improvement, particularly for servers, but a hard limit doesn't seem to be it.

Didn't Rik do something in this area back in 2.4 and decide there weren't many fish in that pond?

--
-bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/