mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jos Hulzink <josh@stack.nl>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Szakacsits Szabolcs <szaka@sienet.hu>,
	Robert Love <rml@tech9.net>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] strict VM overcommit
Date: Sun, 21 Jul 2002 16:33:41 +0200 (CEST)	[thread overview]
Message-ID: <20020721162011.I69041-100000@turtle.stack.nl> (raw)
In-Reply-To: <Pine.NEB.4.44.0207211438440.11656-100000@mimas.fachschaften.tu-muenchen.de>

On Sun, 21 Jul 2002, Adrian Bunk wrote:

> On 21 Jul 2002, Alan Cox wrote:
>
> > I would suggest you do something quite different. Go and read what K&R
> > had to say about the design of Unix. One of the design goals of Unix is
> > that the system does not think it knows better than the administrator.
> > That is one of the reasons unix works well and is so flexible.
>
> The problem is that at the time K&R said this only real men (tm) were
> administrators of UNIX systems. Nowadays clueless people like me are
> administrators of their Linux system at home.  ;-)
>
> With enough stupidity root can always trash his system but if as Robert
> says the state of the system will be that "no allocations will succeed"
> which seems to be a synonymous for "the system is practically dead" it is
> IMHO a good idea to let "swapoff -a return -ENOMEM".
>

Maybe it is an option to add the --I_know_Im_stupid option to the swapoff
command line ? (Also known as the --force flag). This way we can both
return an error when the OS lacks memory and force a swapoff.

Agreed, the system is practically dead when no allocations will succeed,
but maybe killing user tasks when root needs memory or something is an
option... (Better a few angry users than a crashed server, besides, it is
not something that should happen every day)

Jos


  reply	other threads:[~2002-07-21 14:30 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-11 22:28 Robert Love
2002-07-12 17:30 ` [PATCH] strict VM overcommit for stock 2.4 Robert Love
2002-07-18 15:22   ` Szakacsits Szabolcs
2002-07-18 16:31     ` Robert Love
2002-07-18 16:36       ` Szakacsits Szabolcs
2002-07-18 17:42         ` Robert Love
2002-07-18 17:25           ` Szakacsits Szabolcs
2002-07-18 17:31             ` Szakacsits Szabolcs
2002-07-18 18:32               ` Robert Love
2002-07-18 19:58               ` Alan Cox
2002-07-18 18:01                 ` Szakacsits Szabolcs
2002-07-18 18:52                 ` Robert Love
2002-07-18 20:52                   ` Alan Cox
2002-07-19  6:17                 ` Szakacsits Szabolcs
2002-07-18 22:22               ` Rik van Riel
2002-07-19  7:47                 ` Szakacsits Szabolcs
2002-07-18 18:28             ` Robert Love
2002-07-18 17:50               ` Szakacsits Szabolcs
2002-07-18 19:25                 ` stoffel
2002-07-19  5:52                   ` Szakacsits Szabolcs
2002-07-18 18:56               ` Richard B. Johnson
2002-07-18 19:03                 ` Robert Love
2002-07-18 19:19                   ` Richard B. Johnson
2002-07-18 19:22                     ` Robert Love
2002-07-18 20:49                       ` Alan Cox
2002-07-18 19:10                 ` Robert Love
2002-07-18 19:35                   ` Richard B. Johnson
2002-07-18 19:41                     ` Daniel Gryniewicz
2002-07-18 20:23                       ` Richard B. Johnson
2002-07-18 20:43                         ` Daniel Gryniewicz
2002-07-19  7:30                   ` Szakacsits Szabolcs
2002-07-19 18:06                     ` Robert Love
2002-07-18 22:24             ` Rik van Riel
2002-07-18 22:30               ` Robert Love
2002-07-18 22:08 ` [PATCH] strict VM overcommit Adrian Bunk
2002-07-18 22:27   ` Robert Love
2002-07-19 11:02     ` Adrian Bunk
2002-07-20  0:32   ` Alan Cox
2002-07-21  9:10     ` Szakacsits Szabolcs
2002-07-21 13:32       ` Alan Cox
2002-07-21 12:46         ` Adrian Bunk
2002-07-21 14:33           ` Jos Hulzink [this message]
2002-07-22  0:43             ` Thunder from the hill
2002-07-21 16:46           ` Alan Cox
2002-07-21 15:23         ` Szakacsits Szabolcs
2002-07-21 19:01           ` Alan Cox
2002-07-22  8:08             ` Szakacsits Szabolcs
2002-07-22 13:00               ` Alan Cox
2002-07-22 12:45                 ` Hugh Dickins
2002-07-22 14:01                   ` Alan Cox
2002-07-22  1:12           ` Thunder from the hill
2002-07-22  8:03             ` Szakacsits Szabolcs
2002-07-22 10:23               ` Thunder from the hill

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=20020721162011.I69041-100000@turtle.stack.nl \
    --to=josh@stack.nl \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bunk@fs.tum.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@tech9.net \
    --cc=szaka@sienet.hu \
    /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

Powered by JetHome