linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Jonathan Morton <chromi@cyberspace.org>,
	VDA <VDA@port.imtp.ilyichevsk.odessa.ua>,
	Andrea Arcangeli <andrea@suse.de>,
	Rik van Riel <riel@conectiva.com.br>,
	Alexander Viro <viro@math.psu.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux VM design
Date: Mon, 24 Sep 2001 21:16:21 +0200	[thread overview]
Message-ID: <20010924190853Z16175-2757+1600@humbolt.nl.linux.org> (raw)
In-Reply-To: <20010916204528.6fd48f5b.skraw@ithnet.com> <20010924182948Z16175-2757+1593@humbolt.nl.linux.org> <a05100301b7d52f49f7b6@[192.168.239.101]>
In-Reply-To: <a05100301b7d52f49f7b6@[192.168.239.101]>

On September 24, 2001 08:46 pm, Jonathan Morton wrote:
> >  > DP> The arguments in support of aging over LRU that I'm aware of are:
> >>
> >>  DP>   - incrementing an age is more efficient than resetting several LRU
> >>  DP>     list links
> >>  DP>   - also captures some frequency-of-use information
> >>
> >>  Of what use this info can be? If one page is accessed 100 times/second
> >>  and other one once in 10 seconds, they both have to stay in RAM.
> >>  VM should take 'time since last access' into account whan deciding
> >>  which page to swap out, not how often it was referenced.
> >
> >You might want to have a look at this:
> >
> >    http://archi.snu.ac.kr/jhkim/seminar/96-004.ps
> >    (lrfu algorithm)
> >
> >To tell the truth, I don't really see why the frequency information is all
> >that useful either.  Rik suggested it's good for streaming IO but we 
already
> >have effective means of dealing with that that don't rely on any frequency
> >information.
> >
> >So the list of reasons why aging is good is looking really short.
> 
> It's not really frequency information.  If a page is accessed 1000 
> times during a single schedule cycle, that will count as a single 
> increment in the age come the time.  However, *macro* frequency 
> information of this type *is* useful in the case where thrashing is 
> taking place.  You want to swap out the page that is accessed only 
> once every other schedule cycle, before the one accessed every cycle. 

But this happens naturally with LRU.  Think how it works: to get evicted a 
page has to progress all the way from the head to the tail of the LRU list.  
Any page that's accessed frequently is going to keep being put back at the 
head of the list, and only infrequently accessed pages will drop off the tail.

> This is of course moot if one process is being suspended (as it 
> probably should), but the criteria for suspension might include this 
> access information.

OK, that does get at something you can do with aging that you can't do with 
an LRU list: look at the weightings of random pages.  You can't do that with 
the LRU list because there's no efficient way to determine which position a 
page holds in the list.

One application where you would want to know the weightings of random pages 
is defragmentation.  That might become important in the future but we're not 
doing it now.

A little contemplation will probably turn up other uses for this special 
property.

--
Daniel

  reply	other threads:[~2001-09-24 19:09 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-16 15:19 broken VM in 2.4.10-pre9 Ricardo Galli
2001-09-16 15:23 ` Michael Rothwell
2001-09-16 16:33   ` Rik van Riel
2001-09-16 16:50     ` Andreas Steinmetz
2001-09-16 17:12       ` Ricardo Galli
2001-09-16 17:06     ` Ricardo Galli
2001-09-16 17:18       ` Jeremy Zawodny
2001-09-16 18:45       ` Stephan von Krawczynski
2001-09-21  3:16         ` Bill Davidsen
2001-09-21 10:21         ` Stephan von Krawczynski
2001-09-21 14:08           ` Bill Davidsen
2001-09-21 14:23             ` Rik van Riel
2001-09-23 13:13               ` Eric W. Biederman
2001-09-23 13:27                 ` Rik van Riel
2001-09-21 10:43         ` Stephan von Krawczynski
2001-09-21 12:13           ` Rik van Riel
2001-09-21 12:55           ` Stephan von Krawczynski
2001-09-21 13:01             ` Rik van Riel
2001-09-22 11:01           ` Daniel Phillips
2001-09-22 20:05             ` Rik van Riel
2001-09-24  9:36           ` Linux VM design VDA
2001-09-24 11:06             ` Dave Jones
2001-09-24 12:15               ` Kirill Ratkin
2001-09-24 13:29             ` Rik van Riel
2001-09-24 14:05               ` VDA
2001-09-24 14:37                 ` Rik van Riel
2001-09-24 14:42                 ` Rik van Riel
2001-09-24 18:37             ` Daniel Phillips
2001-09-24 19:32               ` Rik van Riel
2001-09-24 17:27                 ` Rob Landley
2001-09-24 21:48                   ` Rik van Riel
2001-09-25  9:58                 ` Daniel Phillips
2001-09-25 16:03               ` bill davidsen
2001-09-24 18:46             ` Jonathan Morton
2001-09-24 19:16               ` Daniel Phillips [this message]
2001-09-24 19:11             ` Dan Mann
2001-09-25 10:55             ` VDA
2001-09-16 18:16     ` broken VM in 2.4.10-pre9 Stephan von Krawczynski
2001-09-16 19:43     ` Linus Torvalds
2001-09-16 19:57       ` Rik van Riel
2001-09-16 20:17       ` Rik van Riel
2001-09-16 20:29       ` Andreas Steinmetz
2001-09-16 21:28         ` Linus Torvalds
2001-09-16 22:47           ` Alex Bligh - linux-kernel
2001-09-16 22:55             ` Linus Torvalds
2001-09-16 22:59           ` Stephan von Krawczynski
2001-09-16 22:14             ` Linus Torvalds
2001-09-16 23:29               ` Stephan von Krawczynski
2001-09-17 15:35             ` Stephan von Krawczynski
2001-09-17 15:51               ` Linus Torvalds
2001-09-17 16:34               ` Stephan von Krawczynski
2001-09-17 16:46                 ` Linus Torvalds
2001-09-17 17:20                 ` Stephan von Krawczynski
2001-09-17 17:37                   ` Linus Torvalds
2001-09-17  0:37       ` Daniel Phillips
2001-09-17  1:07         ` Linus Torvalds
2001-09-17  2:23           ` Daniel Phillips
2001-09-17  5:11           ` Jan Harkes
2001-09-17 12:33             ` Daniel Phillips
2001-09-17 12:41               ` Rik van Riel
2001-09-17 14:49                 ` Daniel Phillips
2001-09-17 16:14               ` Jan Harkes
2001-09-17 16:34                 ` Linus Torvalds
2001-09-17 15:38             ` Linus Torvalds
2001-09-17 12:26           ` Rik van Riel
2001-09-17 15:42             ` Linus Torvalds
2001-09-18 12:04               ` Rik van Riel
2001-09-17 17:33             ` Linus Torvalds
2001-09-17 18:07               ` Linus Torvalds
2001-09-18 12:09               ` Rik van Riel
2001-09-21  3:10       ` Bill Davidsen
2001-09-17  8:06     ` Eric W. Biederman
2001-09-17 12:12       ` Rik van Riel
2001-09-17 15:45         ` Eric W. Biederman
2001-09-25 11:00 Linux VM design VDA
2001-09-25 11:07 ` Rik van Riel

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=20010924190853Z16175-2757+1600@humbolt.nl.linux.org \
    --to=phillips@bonn-fries.net \
    --cc=VDA@port.imtp.ilyichevsk.odessa.ua \
    --cc=andrea@suse.de \
    --cc=chromi@cyberspace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    --cc=viro@math.psu.edu \
    /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).