Ram Gupta wrote:
On 2/9/06, Alan Cox <[email protected]> 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 ([email protected])
"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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
