Re: RSS Limit implementation issue

[Bill Davidsen <davidsen@tmr.com>]

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.

Since the process has little or no control over that it seems 
impractical. And works the wrong way, when there is a ton of free memory 
the process would get a large rss and be killed, while on a loaded 
system it would run.
> 2. Dont kill the process but dont allocate the memory & do yield as we
> do for init process. Modify the scheduler not to chose the process
> which has already allocated rss upto its limit. When rss usage
> fallsbelow its limit then the scheduler may chose it again to run.
> Here there is a scenario when no page of the process has been freed or
> swapped out because there were enough free pages? Then we need a way
> to reschedule the process by forcefully freeing some pages or need to
> kill the process.
>
> I am looking forward for your comments & pros/cons of both approach &
> any other alternatives you might come up with.

First, someone did some work on this a few years ago, you might be able 
to find info looking a rmap posts for the mid 2.4 days.

Second, I think this limitation needs to be enforced only when free 
memory is below some trigger point, when candidates for reclaim would be 
drawn from processes over their rss target.

Finally, it would be good to be aggressive about cleaning dirty pages of 
a process of the target, so pages clould be reclaimed quickly. There are 
a lot of factors in that, useless disk activity being one possible side 
effect.


--
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
-
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/