From: frankeh@us.ibm.com
To: linux-mm@kvack.org
Subject: Re: [RFC] RSS guarantees and limits
Date: Thu, 22 Jun 2000 11:49:51 -0400 [thread overview]
Message-ID: <85256906.0056DB76.00@D51MTA03.pok.ibm.com> (raw)
I assume that in the <workstation> scenario, where there are limited number
of processes, your approach will work just fine.
In a server scenario where you might have lots of processes (with limited
resource requirements) this might have different effects
This inevidably will happen when we move Linux to NUMA or large scale SMP
systems and we apply images like that to webhosting.
Do you think that the resulting RSS guarantees (function of
<mem_size/2*process_count>) will be sufficient ? Or is your assumption,
that for this kind of server apps with lots of running processes, you
better don't overextent your memory and start paging (acceptable
assumption)..
-- Hubertus
Rik van Riel <riel@conectiva.com.br> on 06/22/2000 12:01:18 PM
To: Hubertus Franke/Watson/IBM@IBMUS
cc: linux-mm@kvack.org
Subject: Re: [RFC] RSS guarantees and limits
On Thu, 22 Jun 2000 frankeh@us.ibm.com wrote:
> Seems like a good idea, for ensuring some decent response time.
> This seems similar to what WinNT is doing.
There's a big difference here. I plan on making the RSS limit system
such that most applications should be somewhere between their limit
and their guarantee when the system is under "normal" levels of
memory pressure.
That is, I want to keep global page replacement the primary page
replacement strategy and only use the RSS guarantees and limits to
guide global page replacement and limit the system from impact by
memory hogs.
> Do you envision that the "RSS guarantees" decay over time. I am
> concerned that some daemons hanging out there and which might be
> executed very rarely (e.g. inetd) might hug to much memory
> (cummulatively speaking). I think NT at some point pages the
> entire working set for such apps.
This is what I want to avoid. Of course if a task is really
sleeping it should of course be completely removed from
memory, but a _periodic_ task like top or atd may as well be
protected a bit if memory pressure is low enough.
I know I will have to adjust my rough draft quite a bit to
achieve the wanted effects...
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next reply other threads:[~2000-06-22 15:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-22 15:49 frankeh [this message]
2000-06-22 16:05 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2000-06-23 18:07 frankeh
2000-06-23 14:01 frankeh
2000-06-23 17:56 ` Stephen Tweedie
2000-06-22 23:02 Mark_H_Johnson
2000-06-22 16:22 frankeh
2000-06-22 16:38 ` Rik van Riel
2000-06-22 19:48 ` Jamie Lokier
2000-06-22 19:52 ` Rik van Riel
2000-06-22 20:00 ` Jamie Lokier
2000-06-22 20:07 ` Rik van Riel
2000-06-22 14:41 frankeh
2000-06-22 15:31 ` Rik van Riel
2000-06-21 22:29 Rik van Riel
2000-06-22 18:00 ` John Fremlin
2000-06-22 19:12 ` Rik van Riel
2000-06-22 21:19 ` Stephen Tweedie
2000-06-22 21:37 ` Rik van Riel
2000-06-22 22:48 ` John Fremlin
2000-06-22 23:59 ` Stephen Tweedie
2000-06-23 16:08 ` John Fremlin
2000-06-22 22:39 ` John Fremlin
2000-06-22 23:27 ` Rik van Riel
2000-06-23 0:49 ` Ed Tomlinson
2000-06-23 13:45 ` Rik van Riel
2000-06-23 15:36 ` volodya
2000-06-23 15:52 ` John Fremlin
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=85256906.0056DB76.00@D51MTA03.pok.ibm.com \
--to=frankeh@us.ibm.com \
--cc=linux-mm@kvack.org \
/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