From: Bill Davidsen <davidsen@tmr.com>
To: Ram Gupta <ram.gupta5@gmail.com>,
Linux Kernel mailing List <linux-kernel@vger.kernel.org>
Subject: Re: RSS Limit implementation issue
Date: Fri, 10 Feb 2006 16:41:47 -0500 [thread overview]
Message-ID: <43ED089B.7080508@tmr.com> (raw)
In-Reply-To: <728201270602091310r67a3f2dcq4788199f26a69528@mail.gmail.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
next prev parent reply other threads:[~2006-02-10 21:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-09 21:10 RSS Limit implementation issue Ram Gupta
2006-02-09 23:07 ` Alan Cox
2006-02-10 14:50 ` Ram Gupta
2006-02-10 16:31 ` Kyle Moffett
2006-02-10 22:20 ` Rik van Riel
2006-03-23 16:55 ` Ram Gupta
2006-03-29 20:16 ` Bill Davidsen
2006-03-30 21:41 ` Roger Heflin
2006-04-04 19:28 ` Bill Davidsen
2006-04-05 18:50 ` Roger Heflin
2006-04-07 2:55 ` kingsley
2006-03-31 3:00 ` Peter Chubb
2006-03-31 3:31 ` Bill Davidsen
2006-02-09 23:12 ` Bernd Eckenfels
2006-02-10 21:41 ` Bill Davidsen [this message]
[not found] <mail.linux.kernel/728201270602091310r67a3f2dcq4788199f26a69528@mail.gmail.com>
[not found] ` <06Feb11.024837est.33911@gpu.utcc.utoronto.ca>
2006-02-13 14:52 ` Ram Gupta
[not found] ` <06Feb13.151216est.821021@ugw.utcc.utoronto.ca>
2006-02-13 20:37 ` Ram Gupta
[not found] <5ErmY-5vN-5@gated-at.bofh.it>
[not found] ` <5EGm2-2eZ-27@gated-at.bofh.it>
[not found] ` <5TBku-7fu-3@gated-at.bofh.it>
2006-03-24 23:06 ` Bodo Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43ED089B.7080508@tmr.com \
--to=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ram.gupta5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).