mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Muthian Sivathanu <muthian_s@yahoo.com>
To: David Schwartz <davids@webmaster.com>
Cc: linux-kernel@vger.kernel.org
Subject: RE: limit resident memory size
Date: Fri, 13 Jun 2003 10:02:20 -0700 (PDT)	[thread overview]
Message-ID: <20030613170220.17400.qmail@web40601.mail.yahoo.com> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKMECFDKAA.davids@webmaster.com>

> 	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.

the goals of resource isolation and optimal overall
performance are often in conflict, and there are
definitely cases when one really needs performance
isolation across processes inspite of the slight
performance hit this may entail.

> 	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.
> 

I agree thats an issue -- how to treat shared pages is
a policy decision which may vary with the exact
requirements, but the general mechanism to be able to
monitor resident sets on a per process basis seems to
be useful.  How to treat shared pages could be a
user-specified parameter.

> 	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.
> 

I am concerned about reasonably long running processes
-- in those cases, limiting cpu usage need not
necessarily lead to bounds on resident set size --
what about a process that reads in a large file abt
the size of main memory ? it doesnt need much cpu, but
can fill up your memory.

> 	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.
> 

again, I disagree.  Though it may be true in certain
cases, there are situations when a user knows better
about the relative importance of the processes he
runs. Wherever one desires performance isolation,
having per-process control over resource usage is
definitely a useful mechanism.

Muthian.


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

  reply	other threads:[~2003-06-13 16:48 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
2003-06-13 17:02       ` Muthian Sivathanu [this message]
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=20030613170220.17400.qmail@web40601.mail.yahoo.com \
    --to=muthian_s@yahoo.com \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®