All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.2.19pre1
Date: Sat, 16 Dec 2000 15:13:03 +0100	[thread overview]
Message-ID: <20001216151303.D25150@inspiron.random> (raw)
In-Reply-To: <E1470sk-0001kp-00@the-village.bc.nu>
In-Reply-To: <E1470sk-0001kp-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Dec 15, 2000 at 07:51:04PM +0000

On Fri, Dec 15, 2000 at 07:51:04PM +0000, Alan Cox wrote:
> o	Basic page aging				(Neil Schemenauer)
> 	| This is a beginning to trying to get the VM right

(page aging isn't a matter of correctness of the VM, it's only a matter of
performance basically only during swap [for all other usages lru behaviour is
enough])

About the implementation the swapcache aging is going to be wrong and it could
cause swapcache storms during swap. In 2.2.x we can't implement a kind of
deactivate_page that works on lru, because there's no lru, so all we can do is
to ignore the aging for swap_cache that isn't referenced by anybody (either on
swap or on memory).

Also the implementation is dubios and suboptimal (I'd replace PG_referenced
with page->age instead of mixing the two things, plus page->age is set at
page-freeing time while you want to initialize it only when adding swapcache or
pagecache [this save CPU cycles]).

Even if the patch [after fixing the swapout issue pointed out above] looks safe
I need a bit more time to verify that it doesn't change the balancing of the VM
(the point of aging is to make harder the in-core pages to be freed so it will
somehow increase the swapout factor) and so in the very short term I won't
support the VM-global patch on top of page-aging (to avoid invalidating all the
testing and feedback it had).

For 2.2.19pre2 short term I'd suggest to backout the aging patch and to apply
VM-global against 2.2.18. This will make VM behaviour better regardless
of aging, then if you still feel the need of aging on your 486 8mbyte box
I will try to put your patch on top of VM-global at least after addressing
the swapcache shrinking issue and optimizing it a little bit.

Comments?

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2000-12-16 14:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-15 19:51 Linux 2.2.19pre1 Alan Cox
2000-12-15 20:03 ` [PATCH] Re: Linux 2.2.19pre1 : procfs api Michael Rothwell
2000-12-16  7:05   ` Willy Tarreau
2000-12-16 14:34     ` Michael Rothwell
2000-12-15 20:05 ` [PATCH] Re: Linux 2.2.19pre1 64-bit printk Michael Rothwell
2000-12-15 20:56 ` Linux 2.2.19pre1 Tom Rini
2000-12-16 14:13 ` Andrea Arcangeli [this message]
2000-12-16 16:19   ` Alan Cox
2000-12-16 16:26     ` Andrea Arcangeli
2000-12-16 21:40 ` Andre Hedrick

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=20001216151303.D25150@inspiron.random \
    --to=andrea@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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.