All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Jonathan Morton <chromi@cyberspace.org>,
	mike_phillips@urscorp.com, <linux-kernel@vger.kernel.org>
Subject: Re: VM Requirement Document - v0.0
Date: Thu, 28 Jun 2001 18:02:58 +0200	[thread overview]
Message-ID: <01062818025707.00419@starship> (raw)
In-Reply-To: <OF95A43E53.39291B42-ON84256A79.003D421D@urscorp.com> <01062816393503.00419@starship> <a05100301b760fb217ddc@[192.168.239.101]>
In-Reply-To: <a05100301b760fb217ddc@[192.168.239.101]>

On Thursday 28 June 2001 17:21, Jonathan Morton wrote:
> >There is a simple change in strategy that will fix up the updatedb case
> > quite nicely, it goes something like this: a single access to a page
> > (e.g., reading it) isn't enough to bring it to the front of the LRU
> > queue, but accessing it twice or more is.  This is being looked at.
>
> Say, when a page is created due to a page fault, page->age is set to
> zero instead of whatever it is now.

This isn't quite enough.  We do want to be able to assign a ranking to 
members of the accessed-once set, and we do want to distinguish between newly 
created pages and pages that have aged all the way to zero.

> Then, on the first access, it is
> incremented to one.  All accesses where page->age was previously zero
> cause it to be incremented to one, and subsequent accesses where
> page->age is non-zero cause a doubling rather than an increment.
> This gives a nice heavy priority boost to frequently-accessed pages...

While on that topic, could somebody please explain to me why exponential 
aging is better than linear aging by a suitably chosen increment?  It's clear 
what's wrong with it: after 32 hits you lose all further information.  I 
suspect there are more problems with it than that.

--
Daniel

  reply	other threads:[~2001-06-28 15:59 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-28 12:20 VM Requirement Document - v0.0 mike_phillips
2001-06-28 12:30 ` Alan Cox
2001-06-28 13:33   ` Tobias Ringstrom
2001-06-28 13:37     ` Alan Cox
2001-06-28 14:04       ` Tobias Ringstrom
2001-06-28 14:14         ` Alan Cox
2001-06-28 14:52       ` Daniel Phillips
2001-06-28 14:39 ` Daniel Phillips
2001-06-28 15:21   ` Jonathan Morton
2001-06-28 16:02     ` Daniel Phillips [this message]
2001-06-28 18:01   ` Marco Colombo
2001-07-02 18:42     ` Rik van Riel
2001-07-03 10:33       ` Marco Colombo
2001-07-03 15:04         ` Daniel Phillips
2001-07-03 18:24           ` Daniel Phillips
2001-07-04  8:12           ` Ari Heitner
2001-07-04  9:41           ` Marco Colombo
2001-07-04 15:03             ` Daniel Phillips
2001-07-03 18:29       ` Daniel Phillips
2001-07-04  8:32         ` Marco Colombo
2001-07-04 14:44           ` Daniel Phillips
  -- strict thread matches above, loose matches on Subject: below --
2001-07-05 15:09 mike_phillips
     [not found] <fa.jprli0v.qlofoc@ifi.uio.no>
     [not found] ` <fa.e66agbv.hn0u1v@ifi.uio.no>
2001-07-05  1:49   ` Dan Maas
2001-07-05 13:02     ` Daniel Phillips
2001-07-05 14:00       ` Xavier Bestel
2001-07-05 14:51         ` Daniel Phillips
2001-07-05 15:04         ` Daniel Phillips
2001-07-05 15:00           ` Xavier Bestel
2001-07-05 15:12             ` Daniel Phillips
2001-07-05 15:12           ` Alan Shutko
2001-07-06 19:09           ` Rik van Riel
2001-07-06 21:57             ` Daniel Phillips
     [not found]   ` <002501c104f4/mnt/sendme701a8c0@morph>
2001-07-09 12:17     ` Pavel Machek
2001-07-12 23:46       ` Daniel Phillips
2001-07-13 21:07         ` Pavel Machek
2001-07-04 16:08 mike_phillips
2001-06-27  8:53 Martin Knoblauch
2001-06-27 18:13 ` Rik van Riel
2001-06-28  6:59   ` Martin Knoblauch
2001-06-28 11:27 ` Helge Hafting
2001-06-28 11:54   ` Martin Knoblauch
2001-06-28 12:02   ` Tobias Ringstrom
2001-06-28 12:31     ` Xavier Bestel
2001-06-28 13:05       ` Tobias Ringstrom
     [not found] <fa.oqkojpv.3hosb7@ifi.uio.no>
     [not found] ` <fa.jpsks3v.1o2gag4@ifi.uio.no>
2001-06-27  0:43   ` Dan Maas
2001-06-27  0:45     ` Mike Castle
2001-06-27 10:50     ` Xavier Bestel
2001-06-26 19:58 Jason McMullan
2001-06-26 21:21 ` Rik van Riel
2001-06-26 21:29   ` Jason McMullan
2001-06-26 21:33   ` John Stoffel
2001-06-26 21:42     ` Rik van Riel
2001-06-26 22:21       ` Stefan Hoffmeister
2001-06-26 22:48         ` Jeffrey W. Baker
2001-06-27  0:18           ` Mike Castle
2001-06-28 13:07         ` John Fremlin
2001-06-27 13:36       ` Marco Colombo
2001-06-27  3:55     ` Daniel Phillips
2001-06-27 14:09     ` Pozsar Balazs
2001-06-28 22:47 ` John Fremlin
2001-06-28 22:47   ` John Fremlin
2001-06-30 15:37 ` Pavel Machek
2001-07-10 10:34 ` David Woodhouse

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=01062818025707.00419@starship \
    --to=phillips@bonn-fries.net \
    --cc=chromi@cyberspace.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike_phillips@urscorp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.