mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Szakacsits Szabolcs <szaka@sienet.hu>
Cc: Adrian Bunk <bunk@fs.tum.de>, Robert Love <rml@tech9.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] strict VM overcommit
Date: 22 Jul 2002 14:00:09 +0100	[thread overview]
Message-ID: <1027342809.31782.28.camel@irongate.swansea.linux.org.uk> (raw)
In-Reply-To: <Pine.LNX.4.30.0207220937570.614-100000@divine.city.tvnet.hu>

On Mon, 2002-07-22 at 09:08, Szakacsits Szabolcs wrote:
> > > kill can't kill processes in uninterruptible sleep, etc, etc)? Why the
> > In these cases the kernel infrastructure doesn't support the ability to
> > recover from such a state,
> 
> You again anwered else but ironically you just rebute yourself that
> there are cases when the system knows better then the admin.

And purists consider those flaws

> What the patch claims is no OOM. In the swapoff case potentially there
> are OOM's. This is called bug (the feature not follows the behavior
> what it specified when admin turned it on). Why do you call this bug
> perfectly handled case? What differentiate this case from all other
> when the system knows better not to destroy your data without at least
> a "force" operation for example?

Lets put this bluntly. Your swapdisk is losing sectors left right and
centre. You propose a system where the kernel says "sorry might cause an
OOM" and I lose everything as the disk goes down. Letting the admin set
policy means I can swapoff, maybe lose a program or two to OOM but not
lose the entire system in the process.

Its quite clear that being able to override the kernels assumptions
about what is right are sensible. It always has been


  reply	other threads:[~2002-07-22 11:44 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
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 [this message]
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=1027342809.31782.28.camel@irongate.swansea.linux.org.uk \
    --to=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

all inboxes | Powered by JetHome®