From: Bill Davidsen <davidsen@tmr.com>
To: Ram Gupta <ram.gupta5@gmail.com>
Cc: linux mailing-list <linux-kernel@vger.kernel.org>
Subject: Re: RSS Limit implementation issue
Date: Wed, 29 Mar 2006 15:16:58 -0500 [thread overview]
Message-ID: <442AEB3A.9030503@tmr.com> (raw)
In-Reply-To: <728201270603230855l11faeb6ah33ee88568843068f@mail.gmail.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
next prev parent reply other threads:[~2006-03-30 20:27 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 [this message]
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
[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=442AEB3A.9030503@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.