From: Brian <hiryuu@envisiongames.net>
To: dean gaudet <dean-list-linux-kernel@arctic.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: VM nuisance
Date: Mon, 13 Aug 2001 15:47:34 -0400 [thread overview]
Message-ID: <200108131947.f7DJlKh05718@demai05.mw.mediaone.net> (raw)
In-Reply-To: <Pine.LNX.4.33.0108130716321.20672-100000@twinlark.arctic.org>
In-Reply-To: <Pine.LNX.4.33.0108130716321.20672-100000@twinlark.arctic.org>
On Monday 13 August 2001 10:32 am, dean gaudet wrote:
> On Fri, 10 Aug 2001, Rik van Riel wrote:
> > I haven't got the faintest idea how to come up with an OOM
> > killer which does the right thing for everybody.
>
> maybe the concept is flawed? not saying that it is flawed necessarily,
> but i've often wondered why linux vm issues never seem to be solved in
> the years i've been reading linux-kernel.
>
> if i understand the OOM killer correctly it's intended to make some sort
> of intelligent choice as to which application to shoot when the system
> is out of memory.
As I understand it, the problem is not what to do when the system is out
of memory. The problem is deciding what actually consititutes out of
memory. IOW, if I have a 32 MB system with 512MB of swap, I could have
200MB of swap free and still have a system so far gone that it swaps more
than it works. OTOH, I could have 400MB worth of idle daemons and other
residents taking up swap with a perfectly usable system in RAM.
It would be nice if we could sack a few tasks in swap for awhile so stuff
in RAM could get things done. Something like "if a page gets swapped out,
it'll stay there for at least a minute" should work fine in normal
conditions (since the page has probably been idle for awhile, anyway).
Under memory pressure, the scheduler would pass by any tasks waiting on a
page that was just swapped out.
Now that I've shown off how little I know about the current OOM design,
I'll go sit and be quiet...
-- Brian
> honestly, if applications can't stomach being shot then the bug is in
> the application, not in the kernel. vi can handle being shot because it
> does the right thing: it checkpoints state periodically. it's a simple
> model which any sane application could follow, and many do actually
> follow.
>
> getting shot for OOM or getting shot because of power failure, or 2-bit
> RAM failure, or backhoe fade, or ... what's really the difference?
>
> so why not just use the most simple OOM around: shoot the first app
> which can't get its page. app writers won't like it, and users won't
> like it until the app writers fix their bugs, but then nobody likes the
> current situation, so what's the difference?
>
> maybe kernel support for making checkpointing easier would be a good way
> to advance the science? there certainly are tools which exist that do
> part of the problem already -- except for sockets and pipes and such
> interprocess elements it's pretty trivial to checkpoint. interprocess
> elements probably require some extra kernel support. network elements
> are where it really becomes challenging.
>
> i would happily give up 10 to 20% system resources for checkpoint
> overhead if it meant that i'd be that much closer to a crashproof
> system. after a year the performance deficit would be made up by
> hardware improvements.
>
> i know it's a big pill to swallow, but i've been impressed time and time
> again by the will of linux kernel hackers to just say "this is how it
> will be, because it is the only known way to perfection, deal."
>
> -dean
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-08-13 19:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9li6sf$h5$1@ns1.clouddancer.com>
2001-08-11 1:30 ` VM nuisance David Ford
2001-08-11 2:48 ` Rik van Riel
2001-08-11 2:59 ` H. Peter Anvin
2001-08-11 4:17 ` Rik van Riel
2001-08-11 4:40 ` David Ford
2001-08-11 4:46 ` Rik van Riel
2001-08-11 4:41 ` safemode
2001-08-11 5:00 ` H. Peter Anvin
2001-08-11 13:13 ` Alan Cox
2001-08-11 15:39 ` David Ford
2001-08-11 3:50 ` safemode
2001-08-12 13:09 ` Maciej Zenczykowski
2001-08-12 13:45 ` Rik van Riel
2001-08-16 23:29 ` Justin A
2001-08-17 0:06 ` Dr. Kelsey Hudson
2001-08-17 0:24 ` Justin A
2001-08-17 2:54 ` Dr. Kelsey Hudson
2001-08-12 23:05 ` Dan Mann
2001-08-13 0:01 ` Colonel
2001-08-13 14:32 ` dean gaudet
2001-08-13 19:47 ` Brian [this message]
2001-08-14 8:27 ` Helge Hafting
2001-08-17 13:34 ` Szabolcs Szakacsits
2001-08-17 17:29 ` Rik van Riel
2001-08-14 14:00 ` "VM watchdog"? [was Re: VM nuisance] Pavel Machek
2001-08-16 22:24 ` Jakob Østergaard
2001-08-17 1:26 ` David Ford
2001-08-17 1:41 ` Jakob Østergaard
2001-08-17 9:04 ` Colonel
2001-08-17 20:38 ` David Ford
[not found] <20010811035112.59EC438D01@perninha.conectiva.com.br>
2001-08-11 3:52 ` VM nuisance Rik van Riel
[not found] <no.id>
2001-08-11 16:45 ` Alan Cox
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=200108131947.f7DJlKh05718@demai05.mw.mediaone.net \
--to=hiryuu@envisiongames.net \
--cc=dean-list-linux-kernel@arctic.org \
--cc=linux-kernel@vger.kernel.org \
/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).