public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@bonn-fries.net>
To: Rik van Riel <riel@conectiva.com.br>, <jlnance@intrex.net>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Optimization for use-once pages
Date: Wed, 25 Jul 2001 02:04:30 +0200	[thread overview]
Message-ID: <01072502043009.00520@starship> (raw)
In-Reply-To: <Pine.LNX.4.33L.0107241355090.20326-100000@duckman.distro.conectiva>
In-Reply-To: <Pine.LNX.4.33L.0107241355090.20326-100000@duckman.distro.conectiva>

On Tuesday 24 July 2001 18:56, Rik van Riel wrote:
> On Tue, 24 Jul 2001 jlnance@intrex.net wrote:
> > On Tue, Jul 24, 2001 at 05:47:30AM +0200, Daniel Phillips wrote:
> > > So I decided to look for a new way of approaching the use-once
> > > problem that would easily integrated with our current approach.  
> > > What I came up with is pretty simple: instead of starting a newly
> > > allocated page on the active ring, I start it on the inactive
> > > queue with an age of zero. Then, any time generic_file_read or
> > > write references a page, if its age is zero, set its age to
> > > START_AGE and mark it as unreferenced.
> >
> > This is wonderfully simple and ellegant.
>
> It's a tad incorrect, though.
>
> If a page gets 2 1-byte reads in a microsecond, with this
> patch it would get promoted to the active list, even though
> it's really only used once.

Yes, I expected that to be a relatively rare case however - block 
aligned transfers are much more common, and when we have multiple 
blocks per page we may well want the page to go onto the active list 
because there may be quite a delay between successive block accesses.  
>From there it will be aged normally, not such a horrible thing.

To fix this properly I suspect that just a few microseconds is enough 
delay to pick up the temporal groupings you're talking about.  That's 
not hard to achieve.

> Preferably we'd want to have a "new" list of, say, 5% maximum
> of RAM size, where all references to a page are ignored. Any
> references made after the page falls off that list would be
> counted for page replacement purposes.

At that size you'd run a real risk of missing the tell-tale multiple 
references that mark a page as frequently used.  Think about metadata 
here (right now, that usually just means directory pages, but later... 
who knows).  Once somebody has looked at two files in a directory - 
while the page sits on the "ignore" list - chances are very good 
they'll look at a third, but perhaps not before it drops off the south 
end of the inactive queue.

Well, theorizing can only get us so far before we need to take actual 
measurements.

--
Daniel

  reply	other threads:[~2001-07-25  0:00 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-24  3:47 [RFC] Optimization for use-once pages Daniel Phillips
2001-07-24 12:38 ` jlnance
2001-07-24 16:56   ` Rik van Riel
2001-07-25  0:04     ` Daniel Phillips [this message]
2001-07-25  0:43     ` Anton Altaparmakov
2001-07-25  1:30       ` Daniel Phillips
2001-07-25 21:18         ` Steve Lord
2001-07-24 16:48 ` Linus Torvalds
2001-07-24 17:04   ` Rik van Riel
2001-07-24 18:14     ` Daniel Phillips
2001-07-24 18:15       ` Rik van Riel
2001-07-24 19:41         ` Is /dev/epoll scheduled for official inclusion anytime soon? David E. Weekly
2001-07-24 20:05           ` Rik van Riel
2001-07-24 20:26           ` linux partitioning in IA64 hiufungeric.tse
2001-07-25  9:29             ` Mike A. Harris
2001-07-24 20:24   ` [RFC] Optimization for use-once pages Patrick Dreker
2001-07-24 20:32     ` Rik van Riel
2001-07-24 22:16       ` Patrick Dreker
2001-07-24 22:25         ` Rik van Riel
2001-07-25  0:27           ` Linus Torvalds
2001-07-25  8:20             ` Patrick Dreker
2001-07-25 12:57               ` Martin Devera
2001-07-25 14:16               ` Daniel Phillips
2001-07-24 20:33     ` Linus Torvalds
2001-07-25  1:25       ` Daniel Phillips
2001-07-25  0:18     ` Daniel Phillips
2001-07-24 20:27 ` Marcelo Tosatti
2001-07-24 22:05   ` Rik van Riel
2001-07-24 20:53     ` Marcelo Tosatti
2001-07-24 22:27       ` Rik van Riel
2001-07-24 23:09       ` Daniel Phillips
2001-07-24 19:35         ` Rob Landley
2001-07-25  6:10           ` Marcelo Tosatti
2001-07-25  8:32           ` Eric W. Biederman
2001-07-25 12:53             ` Daniel Phillips
2001-07-25 16:05               ` Eric W. Biederman
2001-07-25 12:57           ` Daniel Phillips
2001-07-25  5:12       ` Andrew Morton
2001-07-25  6:33         ` Marcelo Tosatti
2001-07-30 18:09         ` Marcelo Tosatti
2001-07-24 22:41     ` Daniel Phillips
2001-07-24 22:22   ` Daniel Phillips
2001-07-25  2:31 ` Marcelo Tosatti
     [not found] <010301c11463$1ee00440$294b82ce@connecttech.com>
2001-07-24 17:07 ` Rik van Riel
2001-07-24 17:42   ` Stuart MacDonald
2001-07-24 17:51     ` Rik van Riel
2001-07-24 18:09       ` Stuart MacDonald
2001-07-24 18:15       ` Mike Castle
2001-07-24 18:21         ` Rik van Riel
2001-07-24 17:44   ` Mike Castle
2001-07-24 17:52     ` Rik van Riel
     [not found] <0107251802300B.00907@starship>
2001-07-25 16:41 ` Rik van Riel
2001-07-25 17:46   ` Daniel Phillips
2001-07-26  8:36   ` Eric W. Biederman
2001-07-26 12:06     ` Daniel Phillips
2001-07-26 10:38       ` Marcelo Tosatti
2001-07-26 12:17         ` Daniel Phillips
  -- strict thread matches above, loose matches on Subject: below --
2001-07-26  3:27 Ed Tomlinson

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=01072502043009.00520@starship \
    --to=phillips@bonn-fries.net \
    --cc=jlnance@intrex.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    /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