linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Harkes <jaharkes@cs.cmu.edu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Marcelo Tosatti <marcelo@conectiva.com.br>,
	Rik van Riel <riel@conectiva.com.br>,
	linux-kernel@vger.kernel.org
Subject: Re: page_launder() on 2.4.9/10 issue
Date: Tue, 4 Sep 2001 15:39:59 -0400	[thread overview]
Message-ID: <20010904153958.A31994@cs.cmu.edu> (raw)
In-Reply-To: <20010904135427.A30503@cs.cmu.edu> <E15eLGd-0004Gd-00@the-village.bc.nu>
In-Reply-To: <E15eLGd-0004Gd-00@the-village.bc.nu>

On Tue, Sep 04, 2001 at 07:49:47PM +0100, Alan Cox wrote:
> The VM tuning in the -ac tree is a lot more reliable for most loads (its
> certainly not perfect) and that is because the changes have been done and
> tested one at a time as they are merged. Real engineering process is the
> only way to get this sort of thing working well.

I grabbed the 2.4.9-ac7 patch and looked at some of the files.

Pages allocated with do_anonymous_page are not added to the active list.
as a result there is no aging information for a page until it is
unmapped. So we might be unmapping and allocating swap for shared pages
that another process is using heavily. In which case this page should
always have a high age in in the active list and won't actually get
swapped out. So we get both unnecessary minor faults, and the swap space
will never be reclaimed because we never swap it back in.

Also up aging of mapped process pages is still done in try_to_swap_out,
and all of these pages are still aged down indiscriminately in
refill_inactive_scan. I don't see how it could age that much
differently, so I'm assuming all pages in the active list are basically
at age 0 no matter what aging strategy is picked.

Especially because only down aging is performed periodically by kswapd,
while the only code that ages process pages up is only called once the
system hits free or inactive shortage.

There is some places where tests have been added that should never make
a difference anyways. In reclaim_page and page_launder a page on the
inactive list is checked for page->age. Because the page is not mapped
in any VM it is not possibly for age to be non-zero. If the page was
referenced it would have triggered a minor fault and reactivated the
page.

I guess it is just more carefully papering over the existing problems.

Jan


  reply	other threads:[~2001-09-04 19:40 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: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 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 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 [this message]
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
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-29 13:48     ` Rik van Riel
2001-08-29 13:49       ` Linus Torvalds
2001-08-29 14:38         ` Rik van Riel
2001-08-28 20:01   ` David S. Miller
2001-08-28 20:49     ` Linus Torvalds
2001-08-28 20:56     ` David S. Miller
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=20010904153958.A31994@cs.cmu.edu \
    --to=jaharkes@cs.cmu.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --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;
as well as URLs for NNTP newsgroup(s).