public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Daniel Phillips <phillips@bonn-fries.net>,
	linux-kernel@vger.kernel.org, Ben LaHaise <bcrl@redhat.com>,
	Mike Galbraith <mikeg@wen-online.de>
Subject: Re: [RFC] Optimization for use-once pages
Date: Wed, 25 Jul 2001 15:12:46 +1000	[thread overview]
Message-ID: <3B5E554E.86FDA41F@zip.com.au> (raw)
In-Reply-To: <Pine.LNX.4.33L.0107241903410.20326-100000@duckman.distro.conectiva> <Pine.LNX.4.21.0107241750090.2263-100000@freak.distro.conectiva>

Marcelo Tosatti wrote:
> 
> Daniel's patch adds "drop behind" (that is, adding swapcache
> pages to the inactive dirty) behaviour to swapcache pages.

In some *brief* testing here, it appears that the use-once changes
make an improvement for light-medium workloads.  With swap-intensive
workloads, the (possibly accidental) changes to swapcache aging
in fact improve things a lot, and use-once makes things a little worse.

This is a modified Galbraith test: 64 megs of RAM, `make -j12
bzImage', dual CPU:

2.4.7:			6:54
2.4.7+Daniel's patch	6:06
2.4.7+the below patch	5:56

--- mm/swap.c	2001/01/23 08:37:48	1.3
+++ mm/swap.c	2001/07/25 04:08:59
@@ -234,8 +234,8 @@
 	DEBUG_ADD_PAGE
 	add_page_to_active_list(page);
 	/* This should be relatively rare */
-	if (!page->age)
-		deactivate_page_nolock(page);
+	deactivate_page_nolock(page);
+	page->age = 0;
 	spin_unlock(&pagemap_lru_lock);
 }

This change to lru_cache_add() is the only change made to 2.4.7,
and it provides the 17% speedup for this swap-intensive load.

With the same setup, running a `grep -r /usr/src' in parallel
with a `make -j3 bzImage', the `make -j3' takes:

2.4.7:			5:13
2.4.7+Daniel:		5:03
2.4.7+the above patch:	5:16

With the same setup, running a `grep -r /usr/src' in parallel
with a `make -j1 bzImage', the `make -j1' takes:

2.4.7:			9:25
2.4.7+Daniel:		8:55
2.4.7+the above patch:	9:35

So with lighter loads, use-once is starting to provide benefit, and the
deactivation is too aggressive.

> This is a _new_ thing, and I would like to know how that is changing the
> whole VM behaviour..

Sure.  Daniel's patch radically changes the aging of swapcache
and other pages, and with some workloads it appears that it is
this change which brings about the performance increase, rather
than the intended use-once stuff.

I suspect the right balance here is to take use-once, but *not*
take its changes to lru_cache_add().  That's a separate thing. 

Seems that lru_cache_add() is making decisions at a too-low level, and
they are sometimes wrong.  The decision as to what age to give the page
and whether it should be activated needs to be made at a higher level.


-

  parent reply	other threads:[~2001-07-25  5:06 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-24  3:47 [RFC] Optimization for use-once pages Daniel Phillips
2001-07-24 12:38 ` jlnance
2001-07-24 16:56   ` Rik van Riel
2001-07-25  0:04     ` Daniel Phillips
2001-07-25  0:43     ` Anton Altaparmakov
2001-07-25  1:30       ` Daniel Phillips
2001-07-25 21:18         ` Steve Lord
2001-07-24 16:48 ` Linus Torvalds
2001-07-24 17:04   ` Rik van Riel
2001-07-24 18:14     ` Daniel Phillips
2001-07-24 18:15       ` Rik van Riel
2001-07-24 19:41         ` Is /dev/epoll scheduled for official inclusion anytime soon? David E. Weekly
2001-07-24 20:05           ` Rik van Riel
2001-07-24 20:26           ` linux partitioning in IA64 hiufungeric.tse
2001-07-25  9:29             ` Mike A. Harris
2001-07-24 20:24   ` [RFC] Optimization for use-once pages Patrick Dreker
2001-07-24 20:32     ` Rik van Riel
2001-07-24 22:16       ` Patrick Dreker
2001-07-24 22:25         ` Rik van Riel
2001-07-25  0:27           ` Linus Torvalds
2001-07-25  8:20             ` Patrick Dreker
2001-07-25 12:57               ` Martin Devera
2001-07-25 14:16               ` Daniel Phillips
2001-07-24 20:33     ` Linus Torvalds
2001-07-25  1:25       ` Daniel Phillips
2001-07-25  0:18     ` Daniel Phillips
2001-07-24 20:27 ` Marcelo Tosatti
2001-07-24 22:05   ` Rik van Riel
2001-07-24 20:53     ` Marcelo Tosatti
2001-07-24 22:27       ` Rik van Riel
2001-07-24 23:09       ` Daniel Phillips
2001-07-24 19:35         ` Rob Landley
2001-07-25  6:10           ` Marcelo Tosatti
2001-07-25  8:32           ` Eric W. Biederman
2001-07-25 12:53             ` Daniel Phillips
2001-07-25 16:05               ` Eric W. Biederman
2001-07-25 12:57           ` Daniel Phillips
2001-07-25  5:12       ` Andrew Morton [this message]
2001-07-25  6:33         ` Marcelo Tosatti
2001-07-30 18:09         ` Marcelo Tosatti
2001-07-24 22:41     ` Daniel Phillips
2001-07-24 22:22   ` Daniel Phillips
2001-07-25  2:31 ` Marcelo Tosatti
     [not found] <010301c11463$1ee00440$294b82ce@connecttech.com>
2001-07-24 17:07 ` Rik van Riel
2001-07-24 17:42   ` Stuart MacDonald
2001-07-24 17:51     ` Rik van Riel
2001-07-24 18:09       ` Stuart MacDonald
2001-07-24 18:15       ` Mike Castle
2001-07-24 18:21         ` Rik van Riel
2001-07-24 17:44   ` Mike Castle
2001-07-24 17:52     ` Rik van Riel
     [not found] <0107251802300B.00907@starship>
2001-07-25 16:41 ` Rik van Riel
2001-07-25 17:46   ` Daniel Phillips
2001-07-26  8:36   ` Eric W. Biederman
2001-07-26 12:06     ` Daniel Phillips
2001-07-26 10:38       ` Marcelo Tosatti
2001-07-26 12:17         ` Daniel Phillips
  -- strict thread matches above, loose matches on Subject: below --
2001-07-26  3:27 Ed Tomlinson

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=3B5E554E.86FDA41F@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=bcrl@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=mikeg@wen-online.de \
    --cc=phillips@bonn-fries.net \
    --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