From: Rob Landley <landley@trommello.org>
To: "David Luyer" <david_luyer@pacific.net.au>,
"'Alan Cox'" <alan@lxorguk.ukuu.org.uk>,
"'Oliver Xymoron'" <oxymoron@waste.org>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: vm philosophising
Date: Sat, 19 Jan 2002 13:00:23 -0500 [thread overview]
Message-ID: <20020120020228.SNES23469.femail45.sdc1.sfba.home.com@there> (raw)
In-Reply-To: <004301c1a0a3$bd172a90$46943ecb@pacific.net.au>
In-Reply-To: <004301c1a0a3$bd172a90$46943ecb@pacific.net.au>
On Friday 18 January 2002 11:42 pm, David Luyer wrote:
> And while precommit may be something people ask for, I'd have to say
> many
> of them would, having experienced the difference on identical hardware,
> then realise what a bad idea it was and go back to the current mode.
> That is, it sounds like a big waste of time to implement the
> 'traditional'
> behaviour which Linux is already so much better than.
>
> David.
Precommit basically just asks the application to die when it first allocates
memory if it's even possible for it to die in the most pathlogical usage case
of that memory.
I.E. "die up front" instead of "die while running". (There's no possible way
this can improve performance. If you want to never swap, just don't mount a
swap partition.) You don't even have to change the VM's behavior, it can
still copy on write and such. You just add a test to cause allocations to
fail unnecessarily at times.
Throwing in a little extra code on mmaps and allocations to kill a process
wouldn't be too hard. It would be stupid outside of something like a
financial transaction system (and probably even in there), but it technically
shouldn't be all that hard to do.
Unless I missed something...?
Rob
next prev parent reply other threads:[~2002-01-20 2:03 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.33L.0201162235480.32617-100000@imladris.surriel .com>
2002-01-16 19:04 ` Rik spreading bullshit about VM Andrea Arcangeli
2002-01-16 20:11 ` Jose Luis Domingo Lopez
2002-01-16 20:58 ` Richard Gooch
2002-01-16 21:10 ` Dave Jones
2002-01-16 21:17 ` Rik van Riel
2002-01-17 13:42 ` [lkml] " Ian Soboroff
2002-01-18 3:21 ` ...Re: " Dan Mann
2002-01-17 0:20 ` Luigi Genoni
2002-01-16 20:58 ` Bongani Hlope
2002-01-16 20:55 ` John Levon
2002-01-16 21:21 ` Bongani Hlope
2002-01-16 21:17 ` Craig Knox
2002-01-16 21:29 ` Adam Kropelin
2002-01-17 14:17 ` async buffer flushing reported slowdown (could be a driver issue?) Andrea Arcangeli
2002-01-18 0:28 ` Adam Kropelin
2002-01-16 21:58 ` Rik spreading bullshit about VM Diego Calleja
2002-01-16 22:02 ` Rik van Riel
2002-01-17 14:35 ` bugfix backed out Andrea Arcangeli
2002-01-17 15:04 ` Rik van Riel
2002-01-17 15:52 ` Andrea Arcangeli
2002-01-17 14:25 ` oom failures with mem=4m Andrea Arcangeli
2002-01-16 21:59 ` Rik spreading bullshit about VM Diego Calleja
2002-01-16 22:44 ` Chris Chabot
2002-01-17 8:18 ` Christoph Rohland
2002-01-17 14:13 ` blkdev speedup Andrea Arcangeli
2002-01-17 0:07 ` Rik spreading bullshit about VM Erik Mouw
2002-01-17 0:25 ` J Sloan
2002-01-17 1:15 ` Erik Mouw
2002-01-17 17:40 ` bill davidsen
2002-01-17 14:14 ` Alan Cox
2002-01-18 4:30 ` Bosko Radivojevic
2002-01-18 4:36 ` vm philosophising Rik van Riel
2002-01-18 4:58 ` Matthew Johnson
2002-01-18 5:12 ` Rik van Riel
2002-01-18 5:18 ` Ryan Cumming
2002-01-18 5:43 ` Matthew Johnson
2002-01-21 17:55 ` Bill Davidsen
2002-01-18 6:05 ` Matthew Johnson
2002-01-18 14:42 ` Tommy Faasen
2002-01-18 15:52 ` listmail
2002-01-21 15:50 ` The Doctor What
2002-01-21 16:16 ` Mike Harrold
2002-01-18 15:55 ` Mr. Shannon Aldinger
2002-01-18 18:39 ` Oliver Xymoron
2002-01-18 19:23 ` Alan Cox
2002-01-18 20:17 ` David Schwartz
2002-01-18 21:39 ` Alan Cox
2002-01-19 4:42 ` David Luyer
2002-01-19 18:00 ` Rob Landley [this message]
2002-01-20 5:42 ` Stevie O
2002-01-17 0:38 ` Rik spreading bullshit about VM Rik van Riel
2002-01-17 1:50 ` Nicolas Pitre
2002-01-17 11:45 ` Rik van Riel
2002-01-17 12:02 ` Stephan von Krawczynski
2002-01-17 2:14 ` Andrea Scrimieri
2002-01-17 12:07 ` Rik van Riel
2002-01-17 13:11 ` Andrea Scrimieri
2002-01-17 13:15 ` Rik van Riel
2002-01-17 14:02 ` Alan Cox
2002-01-17 21:41 ` Trever L. Adams
2002-01-18 1:46 ` brian
2002-01-17 1:52 ` Stephen Satchell
2002-01-17 13:26 ` Alan Cox
2002-01-17 15:10 ` clarification about redhat and vm Andrea Arcangeli
2002-01-17 15:21 ` Rik van Riel
2002-01-17 16:17 ` Alan Cox
2002-01-17 16:31 ` Andrea Arcangeli
2002-01-18 16:46 ` Wilhelm Nuesser
2002-01-18 19:07 ` Andrea Arcangeli
2002-01-19 10:50 ` Christoph Rohland
2002-01-19 13:54 ` Alan Cox
2002-01-19 17:38 ` Andrea Arcangeli
2002-01-18 16:53 ` Willi Nüßer
2002-01-19 4:49 vm philosophising David Luyer
2002-01-19 5:46 ` David Weinehall
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=20020120020228.SNES23469.femail45.sdc1.sfba.home.com@there \
--to=landley@trommello.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=david_luyer@pacific.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=oxymoron@waste.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
all inboxes | Powered by JetHome®