linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Scott Kaplan <sfkaplan@cs.amherst.edu>, linux-mm@kvack.org
Subject: Re: About the free page pool
Date: Mon, 02 Sep 2002 14:21:42 -0700	[thread overview]
Message-ID: <3D73D666.9F3A8B0B@zip.com.au> (raw)
In-Reply-To: <Pine.LNX.4.44L.0209021747250.1857-100000@imladris.surriel.com>

Rik van Riel wrote:
> 
> On Mon, 2 Sep 2002, Andrew Morton wrote:
> 
> > > How important is it to maintain a list of free pages?  That is, how
> > > critical is it that there be some pool of free pages from which the only
> > > bookkeeping required is the removal of that page from the free list.
> >
> > There are several reasons, all messy.
> 
> [snip]
> 
> > It's feasible.  It'd take some work.  Probably it would best be implemented
> > via a third list.  That list would be protected by an IRQ-safe lock,
> 
> I don't think we need to bother with the IRQ-safe part.
> 
> It's much simpler if we just do:
> 
> 1) have a normal free list, but have it smaller ...
>    say, between zone->pages_min and zone->pages_low
> 
> 2) if the free pages drop below the low water mark,
>    have either a normal allocator or a kernel thread
>    refill it to the high water mark, from the clean
>    pages list
> 
> 3) have the free+clean target set to something higher,
>    say zone->pages_high ... we could even tune this
>    automatically, if we run out of free+clean pages too
>    often kswapd should probably try to keep more pages
>    clean
> 
> What do you think, would this work?

Well, I'm at a bit of a loss to understand what the objective
of all this is.  Is it so that we can effectively increase the
cache size, by not "wasting" all that free memory?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

  reply	other threads:[~2002-09-02 21:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-02 19:50 Scott Kaplan
2002-09-02 20:33 ` Andrew Morton
2002-09-02 20:50   ` Rik van Riel
2002-09-02 21:21     ` Andrew Morton [this message]
2002-09-02 21:15       ` Rik van Riel
2002-09-02 21:58   ` Scott Kaplan
2002-09-03  1:11     ` Andrew Morton
2002-09-03  1:35       ` Rik van Riel
2002-09-03  5:12       ` William Lee Irwin III
2002-09-03  5:43         ` Andrew Morton
2002-09-03  5:43           ` William Lee Irwin III
2002-09-03 16:46     ` Daniel Phillips

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=3D73D666.9F3A8B0B@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=sfkaplan@cs.amherst.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