mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: "Timothy Miller" <miller@techsource.com>
Cc: "Muthian Sivathanu" <muthian_s@yahoo.com>,
	<linux-kernel@vger.kernel.org>
Subject: RE: limit resident memory size
Date: Thu, 12 Jun 2003 16:37:08 -0700	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKMECFDKAA.davids@webmaster.com> (raw)
In-Reply-To: <3EE90933.8090209@techsource.com>


> David Schwartz wrote:
> >>I would like to limit the maximum resident memory size
> >>of a process within a threshold, i.e. if its virtual
> >>memory footprint exceeds this threshold, it needs to
> >>swap out pages *only* from within its VM space.

> > Why? If you think this is a good way to be nice to other
> > processes, you're
> > wrong.

> Why is he wrong?

	Because increasing the amount of swapping and paging will slow the system
down overall. Other processes will be interrupted more frequently and cache
effectiveness will decline. If the disks are shared, the additional disk
access will slow down other processes on the system as well.

	It's also not clear how shared pages should be handled. If this process
causes large chunks of a shared library to be resident that wouldn't be
otherwise, should this be charged against the process or not? If you exempt
all shared memory, you not only create a whole a malicious process could
drive a truck through but you don't measure accurately.

	If the process has a limited amount of work to do, it's much more sensible
to just let it get done using the memory it needs to run quickly so it can
get out of the way of other processes. If the process has an unlimited
amonut of work to do, it makes more sense to control its use of processor
resources, which will inherently limit its resident set size.

	Basically, which pages should be resident is just one of those things the
system knows better than you. Trying to make things better for one process
may wind up making them worse as the system as a whole bogs down.

	Overall, this just doesn't strike me as a sensible thing to do. Depending
upon what effect he's trying to achieve, there are probably more sensible
ways to do it.

	DS



  reply	other threads:[~2003-06-12 23:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 20:55 Muthian Sivathanu
2003-06-12 22:15 ` David Schwartz
2003-06-12 23:03   ` Muthian Sivathanu
2003-06-12 23:13   ` Timothy Miller
2003-06-12 23:37     ` David Schwartz [this message]
2003-06-13 17:02       ` Muthian Sivathanu
2003-06-13  2:07   ` Rik van Riel
2003-06-13 10:21   ` jlnance

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=MDEHLPKNGKAHNMBLJOLKMECFDKAA.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miller@techsource.com \
    --cc=muthian_s@yahoo.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

all inboxes | Powered by JetHome®