linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrey Savochkin <saw@saw.sw.com.sg>
To: John Fremlin <vii@penguinpowered.com>
Cc: linux-mm@kvack.org, Stephen Tweedie <sct@redhat.com>
Subject: Re: RSS guarantees and limits
Date: Sat, 24 Jun 2000 19:22:45 +0800	[thread overview]
Message-ID: <20000624192245.A6617@saw.sw.com.sg> (raw)
In-Reply-To: <m2og4t9w7j.fsf@boreas.southchinaseas>; from "John Fremlin" on Thu, Jun 22, 2000 at 11:39:44PM

Hello John,

On Thu, Jun 22, 2000 at 11:39:44PM +0100, John Fremlin wrote:
> Stephen Tweedie <sct@redhat.com> writes:
> > It is critically important that when under memory pressure, a
> > system administrator can still log in and kill any runaway
> > processes.  The smaller apps in question here are system daemons
> > such as init, inetd and telnetd, and user apps such as bash and
> > ps.  We _must_ be able to allow them to make at least some
> > progress while the VM is under load.
> 
> I agree completely. It was one of the reasons I suggested that a
> syscall like nice but giving info to the mm layer would be useful. In
> general, small apps (xeyes,biff,gpm) don't deserve any special
> treatment.
> 
> I also said that on a multiuser system it is important that one user
> can't hog the system. In the case where it is impossible for a large
> app to drop root privileges being root wouldn't help unless an
> exception were made for admin caps.

That is exactly my reasons of addressing memory management in the user
beancounter patch:
 - users (and administrator) should have a protection against misbehavior of
   other user's processes;
 - we really care about certain processes which we need for system management
   under memory pressure, rather than about small applications.
Small applications are not always good, as well as big are not bad.
We just want good memory service for those applications which we want to have
it :-)  It hears like tautology, but that it.  It's completely administrator
policy decision.

> The only general solution I can see is to give some process (groups) a
> higher MM priority, by analogy with nice.

Considering the problem, I stated it in a form of guarantee rather than
priority.  Let's consider nice analogy: you can ruin the latency of a
high-priority process by spawning a huge amount lower-priority ones.
Guarantee-like approach gives you configured amount of resources
independently of behavior (or misbehavior) of other processes and users.

> It is critically important that an admin can login to kill a swarm of
> tiny runaway processes. A tiny program that forks every few seconds
> can bring down a machine just as, if not more effectively than, a
> couple of large runaways.

Best regards
					Andrey V.
					Savochkin
--
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/

  parent reply	other threads:[~2000-06-24 11:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-21 22:29 [RFC] " 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
2000-06-24 11:22       ` Andrey Savochkin [this message]
2000-06-27  3:26         ` Stephen C. Tweedie

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=20000624192245.A6617@saw.sw.com.sg \
    --to=saw@saw.sw.com.sg \
    --cc=linux-mm@kvack.org \
    --cc=sct@redhat.com \
    --cc=vii@penguinpowered.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