linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	Mike Fedyk <mfedyk@matchmail.com>,
	Antonio Vargas <wind@cocodriloo.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Marc-Christian Petersen <m.c.p@wolk-project.de>
Subject: Re: Andrea VM changes
Date: Sun, 31 Aug 2003 16:59:32 +0200	[thread overview]
Message-ID: <20030831145932.GU24409@dualathlon.random> (raw)
In-Reply-To: <1062339003.10208.1.camel@dhcp23.swansea.linux.org.uk>

On Sun, Aug 31, 2003 at 03:10:04PM +0100, Alan Cox wrote:
> On Sul, 2003-08-31 at 00:19, Andrea Arcangeli wrote:
> > I've an algorithm that will work, and that will provide very good
> > guarantees to kill the "best" task to make the machine usable again,
> > with the needed protection against the security DoSes, but it's in
> > no-way similar to the current oom killer.
> 
> And -ac has trivial code so you can avoid OOM killing every happening,
> which is pretty much essential for big servers. Perhaps merging that
> as well would be a good idea.

the reservation that you've to do can generate a less optimal
utilization of ram (some buggy app can also fail with it), but I agree
it's a nice feature to be able to return -ENOMEM out of malloc (for
desktops too), instead of killing the task.

However you have the exact same oom deadlocks problem with all non
userspace allocations, like a select, select will deadlock the box in
-ac if you're out of lowmemory, no matter of the non-overcommit
behaviour, same goes for mlock.

And I don't see how you can avoid oom killing to ever happen if the apps
recurse on the stack and growsdown some hundred megs. In such case
you've to oom kill, since there's no synchronous failure path during the
stack growsdown walk.

this of course doesn't change the fact that providing the non overcommit
behaviour (optional), sounds a very good idea, I'm all for it.

I just don't think it solves or hides the other issues, it seems
completely orthogonal to me, because you can still run oom during stack
growsdown.

Andrea

  reply	other threads:[~2003-08-31 14:59 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-30 15:50 Andrea VM changes Marcelo Tosatti
2003-08-30 19:11 ` Marcelo Tosatti
2003-08-30 19:21   ` Marcelo Tosatti
2003-08-30 23:19     ` Andrea Arcangeli
2003-08-30 23:30       ` Marcelo Tosatti
2003-08-30 23:57         ` Andrea Arcangeli
2003-08-31 14:10       ` Alan Cox
2003-08-31 14:59         ` Andrea Arcangeli [this message]
2003-08-31 15:29           ` Alan Cox
2003-08-31 15:59             ` Andrea Arcangeli
2003-09-15  5:16         ` Greg Stark
2003-09-15 10:47           ` Andrea Arcangeli
2003-08-31 11:50     ` Matthias Andree
2003-09-01 19:52       ` Mike Fedyk
2003-09-01 17:59   ` Andrea Arcangeli
     [not found] <Pine.LNX.4.44.0308311353170.15412-100000@logos.cnet>
2003-09-01 17:27 ` Marcelo Tosatti
2003-09-01 17:50   ` Andrea Arcangeli
     [not found] <qL3q.1Pm.3@gated-at.bofh.it>
     [not found] ` <qQ37.2q0.9@gated-at.bofh.it>
2003-09-01  9:15   ` Ihar 'Philips' Filipau
  -- strict thread matches above, loose matches on Subject: below --
2003-09-01  1:02 Dan Kegel
2003-09-01  6:03 ` Rik van Riel
2003-08-31 17:34 Marcelo Tosatti
2003-08-31 17:34 Marcelo Tosatti
2003-08-31 22:46 ` Andrea Arcangeli
2003-09-01  6:01 ` Rik van Riel
2003-09-01 15:54   ` Andrea Arcangeli
2003-08-31 15:51 Dan Kegel
2003-08-31 15:48 ` Jörn Engel
2003-08-31 16:19   ` Dan Kegel
2003-08-31 19:08 ` Jonathan Lundell
2003-08-31 19:22 ` Chris Frey
2003-08-31 23:42   ` Jamie Lokier
2003-09-01 11:47     ` Alan Cox
2003-08-30 15:13 Marcelo Tosatti
2003-08-30 15:41 ` Andrea Arcangeli
2003-09-01 18:26   ` Marcelo Tosatti
2003-09-01 18:36     ` Andrea Arcangeli
2003-09-01 19:00   ` Marcelo Tosatti
2003-09-01 19:05     ` Andrea Arcangeli
2003-09-02 20:51       ` Marcelo Tosatti

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=20030831145932.GU24409@dualathlon.random \
    --to=andrea@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.c.p@wolk-project.de \
    --cc=marcelo@conectiva.com.br \
    --cc=mfedyk@matchmail.com \
    --cc=wind@cocodriloo.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;
as well as URLs for NNTP newsgroup(s).