public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rik van Riel <H.H.vanRiel@fys.ruu.nl>,
	"Stephen C. Tweedie" <sct@dcs.ed.ac.uk>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: new allocation algorithm
Date: Wed, 1 Apr 1998 21:28:49 +0100	[thread overview]
Message-ID: <199804012028.VAA04493@dax.dcs.ed.ac.uk> (raw)
In-Reply-To: <Pine.LNX.3.95.980327092811.6613C-100000@penguin.transmeta.com>

Hi,

On Fri, 27 Mar 1998 09:30:40 -0800 (PST), Linus Torvalds
<torvalds@transmeta.com> said:

> The current scheme is fairly efficient and extremely stable, and gives
> good behaviour for the cases we _really_ care about (pageorders 0, 1 and
> to some degree 2). It comes reasonably close to working for the higher
> orders too, but they really aren't as critical..

Sorry to put a spanner in the works at this stage, but there's
something we haven't really considered yet in the page balancing.  The
aim I'm currently working towards is to eliminate free memory as much
as possible, by replacing "free" space with reserved, lazy-reclaimed
cache memory.  We ought to be able to maintain 5-10% memory in this
form with much less performance impact than we would have if that
memory was truly free, but the downside is that this nearly-free
memory is not on our free page lists and therefore we have no simple
way of assessing the fragmentation of the lazy-reclaimable pages.

Now, this is both a blessing and a curse.  The positive side is that
we can do what to some extent happens today, and keep as much memory
as possible on the lazy list in the blind hope that we will be able to
find free higher order pages when we need them by returning lazy pages
to the free list one by one.  The drawback is that we don't have an
easy way of suspending kswapd when we get enough free higher order
pages.

This is just an observation --- we cannot tune this stuff until it is
stable enough to integrate, but the impact on our free space
heuristics may be worth thinking about now.

--Stephen

      parent reply	other threads:[~1998-04-02 19:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-03-27  9:03 new allocation algorithm Rik van Riel
1998-03-27 17:30 ` Linus Torvalds
1998-03-27 18:33   ` Benjamin C.R. LaHaise
1998-03-30 15:07   ` Rik van Riel
1998-04-01 20:28   ` Stephen C. Tweedie [this message]

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=199804012028.VAA04493@dax.dcs.ed.ac.uk \
    --to=sct@dcs.ed.ac.uk \
    --cc=H.H.vanRiel@fys.ruu.nl \
    --cc=linux-mm@kvack.org \
    --cc=torvalds@transmeta.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