Re: RSS Limit implementation issue

[Bill Davidsen <davidsen@tmr.com>]

Ram Gupta wrote:
> On 2/9/06, Alan Cox <alan@lxorguk.ukuu.org.uk> 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@tmr.com)
"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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/