public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel@vger.kernel.org
Subject: Re: page_launder() on 2.4.9/10 issue
Date: Tue, 4 Sep 2001 16:43:07 -0400	[thread overview]
Message-ID: <20010904164306.A1387@cs.cmu.edu> (raw)
In-Reply-To: <20010904112629.A27988@cs.cmu.edu> <Pine.LNX.4.33L.0109041320271.7626-100000@imladris.rielhome.conectiva>
In-Reply-To: <Pine.LNX.4.33L.0109041320271.7626-100000@imladris.rielhome.conectiva>

On Tue, Sep 04, 2001 at 01:27:50PM -0300, Rik van Riel wrote:
> I've been working on a CPU and memory efficient reverse
> mapping patch for Linux, one which will allow us to do
> a bunch of optimisations for later on (infrastructure)
> and has as its short-term benefit the potential for
> better page aging.
> 
> It seems the balancing FreeBSD does (up aging +3, down
> aging -1, inactive list in LRU order as extra stage) is
> working nicely on my laptop now, but I don't think I'll
> be releasing that as part of the patch ...
> 
> 	http://www.surriel.com/patches/2.4/2.4.8-ac12-pmap3

I like the fact that it completely removes the vm crawling swap_out
path. It also does aging more sanely because it now can take everything
into account. It also works around the problems of anonymous pages that
aren't aged until they are added to the swap cache.

It should also minimize unnecessary minor page faults because the
unmapping is done for all pte's once the page->age hits zero, and
frequently used pages should not grabbing and lock down swapspace that
they won't be able to give up (until the process exits).

The pte_chain allocation stuff looks a bit scary, where did you want to
reclaim them from when memory runs out, unmap existing pte's?

One thing that might be nice, and showed a lot of promise here is to
either age down by subtracting instead of dividing to make it less
aggressive. It is already hard enough for pages to get referenced enough
to move up the scale.

Or use a similar approach as I have in my patch, age up periodically,
but only age down when there is memory shortage, This gives a slight
advantage to processes that were running when there was not much VM
pressure. When something starts hogging memory, it is penalized a bit
for disturbing the peace, but the agressive down aging will quickly
rebalance, typically within about 3 calls to do_try_to_free_pages.

I might port your patch over to Linus's 2.4.10-pre tree to play with it.
It could very well be a significant improvement because it does address
many of the issues that I ran into.

Jan


  parent reply	other threads:[~2001-09-04 20:43 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-28  3:36 page_launder() on 2.4.9/10 issue Marcelo Tosatti
2001-08-28 18:07 ` Daniel Phillips
2001-08-28 18:17   ` Linus Torvalds
2001-08-30  1:36     ` Daniel Phillips
2001-09-03 14:57     ` Marcelo Tosatti
2001-09-04 15:26       ` Jan Harkes
2001-09-04 15:24         ` Marcelo Tosatti
2001-09-04 17:14           ` Jan Harkes
2001-09-04 15:53             ` Marcelo Tosatti
2001-09-04 19:33             ` Daniel Phillips
2001-09-06 11:52             ` Rik van Riel
2001-09-06 12:31               ` Daniel Phillips
2001-09-06 12:32                 ` Rik van Riel
2001-09-06 12:53                   ` Daniel Phillips
2001-09-06 13:03                     ` Rik van Riel
2001-09-06 13:18                       ` Kurt Garloff
2001-09-06 13:23                         ` Rik van Riel
2001-09-06 13:28                         ` Alan Cox
2001-09-06 13:29                           ` Rik van Riel
2001-09-06 16:45                         ` Daniel Phillips
2001-09-06 16:57                           ` Rik van Riel
2001-09-06 17:22                             ` Daniel Phillips
2001-09-06 19:25                               ` Rik van Riel
2001-09-06 19:45                                 ` Daniel Phillips
2001-09-06 19:52                                   ` Rik van Riel
2001-09-07  0:32                                     ` Kurt Garloff
2001-09-06 19:53                                   ` Mike Fedyk
2001-09-06 17:35                         ` Mike Fedyk
2001-09-06 13:10                 ` Stephan von Krawczynski
2001-09-06 13:23                   ` Alex Bligh - linux-kernel
2001-09-06 13:42                     ` Stephan von Krawczynski
2001-09-06 14:01                       ` Alex Bligh - linux-kernel
2001-09-06 14:39                         ` Stephan von Krawczynski
2001-09-06 15:02                           ` Alex Bligh - linux-kernel
2001-09-06 15:07                             ` Rik van Riel
     [not found]                               ` <Pine.LNX.4.33L.0109061206020.31200-100000@imladris.rielhome.con ectiva>
2001-09-06 15:16                                 ` Alex Bligh - linux-kernel
2001-09-06 15:10                             ` Stephan von Krawczynski
2001-09-06 15:18                               ` Alex Bligh - linux-kernel
2001-09-06 17:34                                 ` Daniel Phillips
2001-09-06 17:32                                   ` Alex Bligh - linux-kernel
2001-09-06 13:54                     ` M. Edward Borasky
2001-09-06 14:39                       ` Alan Cox
2001-09-06 16:20                         ` Victor Yodaiken
2001-09-06 17:33                       ` Daniel Phillips
2001-09-06 17:51                   ` Daniel Phillips
2001-09-06 21:01                     ` [RFC] Defragmentation proposal: preventative maintenance and cleanup [LONG] Alex Bligh - linux-kernel
2001-09-07  6:35                       ` Daniel Phillips
2001-09-07  8:58                         ` Alex Bligh - linux-kernel
2001-09-07  9:15                           ` Alex Bligh - linux-kernel
2001-09-07  9:28                             ` Alex Bligh - linux-kernel
2001-09-07 21:38                             ` Daniel Phillips
2001-09-07 21:56                           ` Daniel Phillips
2001-09-07 12:30                     ` page_launder() on 2.4.9/10 issue Stephan von Krawczynski
2001-09-04 16:27         ` Rik van Riel
2001-09-04 17:13           ` Jan Harkes
2001-09-04 15:56             ` Marcelo Tosatti
2001-09-04 17:54               ` Jan Harkes
2001-09-04 16:37                 ` Marcelo Tosatti
2001-09-04 18:49                 ` Alan Cox
2001-09-04 19:39                   ` Jan Harkes
2001-09-04 20:25                     ` Alan Cox
2001-09-06 11:23                       ` Rik van Riel
2001-09-04 19:54                 ` Andrea Arcangeli
2001-09-04 18:36                   ` Marcelo Tosatti
2001-09-04 20:10                   ` Daniel Phillips
2001-09-04 22:04                     ` Andrea Arcangeli
2001-09-05  2:41                       ` Daniel Phillips
2001-09-06 11:18                   ` Rik van Riel
2001-09-04 17:35             ` Daniel Phillips
2001-09-04 20:43           ` Jan Harkes [this message]
2001-09-06 11:21             ` Rik van Riel
     [not found] <20010828180108Z16193-32383+2058@humbolt.nl.linux.org.suse.lists.linux.kernel>
     [not found] ` <Pine.LNX.4.33.0108281110540.8754-100000@penguin.transmeta.com.suse.lists.linux.kernel>
2001-08-28 19:14   ` Andi Kleen
2001-08-28 20:01     ` David S. Miller
2001-08-28 20:49       ` Linus Torvalds
2001-08-28 20:56         ` David S. Miller
2001-08-29 13:48     ` Rik van Riel
2001-08-29 13:49       ` Linus Torvalds
2001-08-29 14:38         ` Rik van Riel
  -- strict thread matches above, loose matches on Subject: below --
2001-09-27 23:14 Samium Gromoff

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=20010904164306.A1387@cs.cmu.edu \
    --to=jaharkes@cs.cmu.edu \
    --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