From: Linus Torvalds <torvalds@transmeta.com>
To: Mark_H_Johnson.RTS@raytheon.com
Cc: "Juan J. Quintela" <quintela@fi.udc.es>,
linux-mm@kvack.org, riel@conectiva.com.br
Subject: Re: pre8: where has the anti-hog code gone?
Date: Mon, 15 May 2000 09:01:03 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.10.10005150858060.3588-100000@penguin.transmeta.com> (raw)
In-Reply-To: <852568E0.0056F0BB.00@raylex-gh01.eo.ray.com>
On Mon, 15 May 2000 Mark_H_Johnson.RTS@raytheon.com wrote:
>
> I guess I have a "philosophy question" - one where I can't quite understand the
> situation that we are in.
> What is the problem that killing processes is curing?
> I understand that the code that [has been/still is?] killing processes is doing
> so because there is no "free physical memory" - right now. Yet we have had code
> to do a schedule() instead of killing the job, and gave the system the chance to
> "fix" the lack of free physical memory problem (e.g., by writing dirty pages to
> a mapped file or swap space on disk). From what I read from Juan's message
> below, I guess this code has been lost or replaced by something more hostile to
> user applications.
This is actually how Linux _used_ to work, a long long time ago. It is
very simple, and it actually worked very well indeed.
Until somebody _really_ starts to eat up memory, at which point it results
in a machine that is completely dead to the world, doing nothing but
swapping pages in and out again.
The "wait until memory is free" approach works very well under many loads,
it's just that it has some rather unfortunate pathological behaviour that
is completely unacceptable. At some point you just have to say "Enough!",
and start killing something.
The bug, of course, is that wehave been quite a bit too eager to do so;)
Linus
--
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/
next prev parent reply other threads:[~2000-05-15 16:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-05-15 14:50 Mark_H_Johnson.RTS
2000-05-15 15:58 ` Rik van Riel
2000-05-15 16:01 ` Linus Torvalds [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-05-12 23:37 Rik van Riel
2000-05-13 15:28 ` Linus Torvalds
2000-05-13 18:14 ` Juan J. Quintela
2000-05-13 21:24 ` Arjan van de Ven
2000-05-13 21:59 ` Juan J. Quintela
2000-05-14 3:41 ` Linus Torvalds
2000-05-14 8:45 ` Arjan van de Ven
2000-05-15 1:37 ` Linus Torvalds
2000-05-14 10:52 ` Ingo Molnar
2000-05-14 10:55 ` Ingo Molnar
2000-05-14 11:28 ` Ingo Molnar
2000-05-14 12:01 ` Rik van Riel
2000-05-14 12:12 ` Ingo Molnar
2000-05-14 12:19 ` Ingo Molnar
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=Pine.LNX.4.10.10005150858060.3588-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=Mark_H_Johnson.RTS@raytheon.com \
--cc=linux-mm@kvack.org \
--cc=quintela@fi.udc.es \
--cc=riel@conectiva.com.br \
/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