From: Linus Torvalds <torvalds@transmeta.com>
To: Rik van Riel <H.H.vanRiel@fys.ruu.nl>
Cc: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>, linux-mm <linux-mm@kvack.org>
Subject: Re: your mail
Date: Wed, 25 Feb 1998 14:48:15 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.3.95.980225144057.8068C-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.3.91.980225230741.1545A-100000@mirkwood.dummy.home>
On Wed, 25 Feb 1998, Rik van Riel wrote:
>
> I've just come up with a very simple idea to limit
> thrashing, and I'm asking you if you want it implemented
> (there's some cost involved :-( ).
>
> We could simply prohibit the VM subsystem from swapping
> out pages which have been allocated less than one second
> ago, this way the movement of pages becomes 'slower', and
> thrashing might get somewhat less.
I'm _really_ nervous about "rate-based" limiting. Personally I think that
it only makes sense for things like networking, and even there it had
better be done by hardware.
The reason I dislike rate-based things is that it is _so_ hard to give any
kind of guarantees at all on the sanity of the thing. You can tweak the
rates, but they don't have any logic to them, and most importantly they
are very hard to make self-tweaking.
I tend to prefer a "balancing" approach to these problems: the important
part about balancing is that while it may not have some specific
well-defined behaviour that you can point your finger to ("will not page
out the same page that it paged in within 5 seconds"), the basic approach
is to write something that doesn't have any hard rules but that TENDS
towards some certain goal.
That way you get algorithms that you can be fairly confident work well in
the normal cases (because you test those normal cases), and because there
are no hard rules you also don't get strange "edges" when something
unexpected happens: performance may well degrade badly, but it degrades
_softly_ rather than in quantisized jumps.
Linus
next prev parent reply other threads:[~1998-02-25 22:48 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-02-25 22:15 Rik van Riel
1998-02-25 22:48 ` Linus Torvalds [this message]
1998-02-25 23:26 ` your mail Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2000-03-28 8:19 pnilesh
2000-03-28 13:26 ` Stephen C. Tweedie
2000-09-04 12:01 Sahil
2000-09-04 15:35 ` your mail Rik van Riel
2001-06-08 1:36 jnn
2001-06-08 13:16 ` your mail Ralf Baechle
2001-08-04 11:10 Mahmoud Taghizadeh
2001-08-04 13:18 ` your mail Francois Romieu
2002-01-02 14:20 mehul radheshyam choube
2002-01-03 16:40 ` your mail Rik van Riel
2002-04-21 14:54 raciel
2002-04-21 19:12 ` your mail William Lee Irwin III
2003-01-24 5:08 (unknown), Anoop J.
2003-01-24 5:11 ` your mail David Lang
2003-01-24 6:06 ` John Alvord
2003-01-25 2:29 ` Jason Papadopoulos
2003-01-25 2:26 ` Larry McVoy
2003-01-25 17:47 ` Eric W. Biederman
2003-01-25 23:10 ` Larry McVoy
2003-01-26 8:12 ` David S. Miller
2003-01-24 5:54 Anoop J.
2003-01-24 6:28 ` David Lang
2003-01-24 8:51 ` Anoop J.
2003-01-24 8:48 ` David Lang
2003-01-24 9:49 ` Anoop J.
2003-01-24 19:14 ` David Lang
2003-01-24 19:40 ` Maciej W. Rozycki
[not found] <1131.86.55.168.2.1170690089.squirrel@mail.thinknet.ro>
2007-02-05 12:36 ` Joerg Roedel
2010-06-16 16:33 Jan Kara
2010-06-16 22:15 ` your mail Dave Chinner
2010-06-22 2:59 ` Wu Fengguang
2010-06-22 13:54 ` Jan Kara
2010-06-22 14:12 ` Wu Fengguang
2012-10-04 16:50 Andrea Arcangeli
2012-10-04 18:17 ` your mail Christoph Lameter
2017-04-10 11:03 [PATCH -v2 0/9] mm: make movable onlining suck less Michal Hocko
2017-04-15 12:17 ` Michal Hocko
2017-04-17 5:47 ` your mail Joonsoo Kim
2017-04-17 8:15 ` Michal Hocko
2017-04-20 1:27 ` Joonsoo Kim
2017-04-20 7:28 ` Michal Hocko
2017-04-20 8:49 ` Michal Hocko
2017-04-20 11:56 ` Vlastimil Babka
2017-04-20 12:13 ` Michal Hocko
2017-04-21 4:38 ` Joonsoo Kim
2017-04-21 7:16 ` Michal Hocko
2017-04-24 1:44 ` Joonsoo Kim
2017-04-24 7:53 ` Michal Hocko
2017-04-25 2:50 ` Joonsoo Kim
2017-04-26 9:19 ` Michal Hocko
2017-04-27 2:08 ` Joonsoo Kim
2017-04-27 15:10 ` Michal Hocko
[not found] <20190225201635.4648-1-hannes@cmpxchg.org>
2019-02-26 23:49 ` Roman Gushchin
2023-05-10 19:01 [PATCH] maple_tree: Fix a few documentation issues, Thomas Gleixner
2023-05-15 19:27 ` your mail Liam R. Howlett
2023-05-15 21:16 ` Thomas Gleixner
2023-05-16 22:47 ` Thomas Gleixner
2023-05-23 13:46 ` Liam R. Howlett
2025-02-24 22:52 [PATCH v7 0/7] mseal system mappings jeffxu
2025-02-25 15:18 ` Lorenzo Stoakes
2025-02-26 0:12 ` Jeff Xu
2025-02-26 5:42 ` your mail Lorenzo Stoakes
2025-02-28 0:55 ` Jeff Xu
2025-02-28 9:35 ` Lorenzo Stoakes
2025-02-28 17:24 ` Jeff Xu
2025-02-28 17:30 ` Lorenzo Stoakes
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.3.95.980225144057.8068C-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=H.H.vanRiel@fys.ruu.nl \
--cc=linux-mm@kvack.org \
--cc=sct@dcs.ed.ac.uk \
/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).