All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Duraid Madina" <duraid@fl.net.au>
To: <linux-kernel@vger.kernel.org>
Subject: VM: Where do we stand?
Date: Wed, 23 Jan 2002 20:32:03 +1100	[thread overview]
Message-ID: <000901c1a3f0$d2e44ba0$022a17ac@simplex> (raw)

I'm sure at least some of you will immediately recognize these words:

>
>Swap allocation is terrible.  Linux uses a linear array which it scans
>looking for a free swap block.  It does a relatively simple swap
>cluster cache, but eats the full linear scan if that fails which can be
>terribly nasty.  The swap clustering algorithm is a piece of crap, 
>too -- once swap becomes fragmented, the linux swapper falls on its
face.
>
>It does read-ahead based on the swapblk which wouldn't be bad if it
>clustered writes by object or didn't have a fragmentation problem.
>As it stands, their read clustering is useless.  Swap deallocation is 
>fast since they are using a simple reference count array.
>
>File read-ahead is half-hazard at best.
>
>The paging queues ( determing the age of the page and whether to 
>free or clean it) need to be written... the algorithms being used
>are terrible.
>
> * For the nominal page scan, it is using a one-hand clock algorithm.  
>   All I can say is:  Oh my god!  Are they nuts?  That was abandoned
>   a decade ago.  The priority mechanism they've implemented is nearly
>   useless.
>
> * To locate pages to swap out, it takes a pass through the task list. 
>   Ostensibly it locates the task with the largest RSS to then try to
>   swap pages out from rather then select pages that are not in use.
>   From my read of the code, it also botches this badly.
>
>Linux does not appear to do any page coloring whatsoever, but it would
>not be hard to add it in.
>

	Where does Linux stand, three years on? An O(1) scheduler is
nice, but I tell you what'd be even nicer...

	coming out for some food, (it's dark out)
	Duraid



             reply	other threads:[~2002-01-23  9:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-23  9:32 Duraid Madina [this message]
2002-01-23  9:44 ` VM: Where do we stand? Rik van Riel
2002-01-23 17:12 ` Daniel Phillips
2002-01-24  9:57 ` Henning P. Schmiedehausen
2002-01-24 12:16   ` 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='000901c1a3f0$d2e44ba0$022a17ac@simplex' \
    --to=duraid@fl.net.au \
    --cc=linux-kernel@vger.kernel.org \
    /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.