linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: yannis@cc.gatech.edu (Yannis Smaragdakis)
To: Rik van Riel <riel@conectiva.com.br>
Cc: Andrea Arcangeli <andrea@suse.de>,
	"Stephen C. Tweedie" <sct@redhat.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	Jens Axboe <axboe@suse.de>, Alan Cox <alan@redhat.com>,
	Derek Martin <derek@cerberus.ne.mediaone.net>,
	davem@redhat.com, linux-mm@kvack.org,
	Yannis Smaragdakis <yannis@cc.gatech.edu>
Subject: Re: [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on
Date: Mon, 17 Jul 2000 03:09:06 -0400 (EDT)	[thread overview]
Message-ID: <200007170709.DAA27512@ocelot.cc.gatech.edu> (raw)
In-Reply-To: <Pine.LNX.4.21.0007111503520.10961-100000@duckman.distro.conectiva> from "Rik van Riel" at Jul 11, 2000 03:06:38 PM

> On Tue, 11 Jul 2000, Rik van Riel wrote:
> And that is correct behaviour. The problem with LRU is that the
> "eventually" is too short, but proper page aging is as close to
> LFU (least _frequently_ used) as it is to LRU. In that case any
> page which was used only once (or was only used a long time ago)
> will be freed before a page which has been used more often
> recently will be.


I'm a Linux kernel newbie and perhaps I should keep my mouth shut, but
I have done a bit of work in memory management and I can't resist
putting my 2c in.


Although I agree with Rik in many major points, I disagree in that I
don't think that page aging should be frequency-based. Overall, I strongly
believe that frequency is the wrong thing to be measuring for deciding
which page to evict from RAM. The reason is that a page that is brought
to memory and touched 1000 times in relatively quick succession is *not*
more valuable than one that is brought to memory and only touched once. 
Both will cause exactly one page fault. Also, one should be cautious of
pages that are brought in RAM, touched many times, but then stay untouched
for a long time. Frequency should never outweigh recency--the latter is
a better predictor, as OS designers have found since the early 70s.


Having said that, LRU is certainly broken, but there are other ways to
fix it. I'll shamelessly plug a paper by myself, Scott Kaplan, and
Paul Wilson, from SIGMETRICS 99. It is in:
	http://www.cc.gatech.edu/~yannis/eelru.ps.gz
(Sorry for the PS, but it compresses well and the original is >3MB.)

I'll be glad to answer questions. The main idea is that we can keep
rough page "ages" (where "age" refers to recency) not only for pages
in RAM, but also for recently evicted pages. Then if we detect that
our overall eviction strategy is wrong (i.e., we touch lots of the
pages we recently evicted), we adapt it by evicting more recently 
touched pages (sounds hacky, but it is actually very clean).

The results are very good (even better than in the paper, as we have
improved the algorithm since).


Back to my cave...
	Yannis.
--
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/

  reply	other threads:[~2000-07-17  7:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20000629114407.A3914@redhat.com>
     [not found] ` <Pine.LNX.4.21.0006291330520.1713-100000@inspiron.random>
2000-06-29 13:00   ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Stephen C. Tweedie
2000-07-06 10:35     ` Andrea Arcangeli
2000-07-06 13:29       ` Stephen C. Tweedie
2000-07-09 17:11         ` Swap clustering with new VM Marcelo Tosatti
2000-07-09 20:53           ` Andrea Arcangeli
2000-07-11  9:36             ` Stephen C. Tweedie
2000-07-09 20:31         ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Andrea Arcangeli
2000-07-11 11:50           ` Stephen C. Tweedie
2000-07-11 16:17             ` Andrea Arcangeli
2000-07-11 16:36               ` Juan J. Quintela
2000-07-11 17:33                 ` Andrea Arcangeli
2000-07-11 17:45                   ` Rik van Riel
2000-07-11 17:54                     ` Andrea Arcangeli
2000-07-11 18:03                       ` Juan J. Quintela
2000-07-11 19:32                         ` Andrea Arcangeli
2000-07-12  0:05                           ` John Alvord
2000-07-12  0:52                             ` Andrea Arcangeli
2000-07-12 18:02                             ` Rik van Riel
2000-07-14  8:51               ` Stephen C. Tweedie
2000-07-11 17:32           ` Rik van Riel
2000-07-11 17:41             ` Andrea Arcangeli
2000-07-11 17:47               ` Rik van Riel
2000-07-11 18:00                 ` Andrea Arcangeli
2000-07-11 18:06                   ` Rik van Riel
2000-07-17  7:09                     ` Yannis Smaragdakis [this message]
2000-07-17  9:28                       ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on Stephen C. Tweedie
2000-07-17 13:01                         ` James Manning
2000-07-17 14:32                           ` Scott F. Kaplan
2000-07-17 14:53                         ` Rik van Riel
2000-07-17 16:44                           ` Manfred Spraul
2000-07-17 17:02                             ` Rik van Riel
2000-07-17 18:55                           ` Yannis Smaragdakis
2000-07-17 19:57                           ` John Fremlin
2000-07-17 14:46                       ` Alan Cox
2000-07-17 14:55                         ` Scott F. Kaplan
2000-07-17 15:31                           ` Rik van Riel
2000-07-14  9:01                   ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on 2.4.0-test2 Stephen C. Tweedie
2000-07-11 18:13               ` Juan J. Quintela
2000-07-11 20:57                 ` Roger Larsson
2000-07-11 22:49                   ` Juan J. Quintela
2000-07-12 16:01               ` Kev
2000-07-06 13:54       ` [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on2.4.0-test2 Roman Zippel

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=200007170709.DAA27512@ocelot.cc.gatech.edu \
    --to=yannis@cc.gatech.edu \
    --cc=alan@redhat.com \
    --cc=andrea@suse.de \
    --cc=axboe@suse.de \
    --cc=davem@redhat.com \
    --cc=derek@cerberus.ne.mediaone.net \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@conectiva.com.br \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.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