All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@arcor.de>
To: William Lee Irwin III <wli@holomorphy.com>,
	Andrew Morton <akpm@zip.com.au>
Cc: Rik van Riel <riel@conectiva.com.br>,
	Dave McCracken <dmccr@us.ibm.com>,
	Linux Memory Management <linux-mm@kvack.org>
Subject: Re: [PATCH] Optimize out pte_chain take three
Date: Sat, 13 Jul 2002 16:45:38 +0200	[thread overview]
Message-ID: <E17TO9S-0003JO-00@starship> (raw)
In-Reply-To: <20020710222210.GU25360@holomorphy.com>

On Thursday 11 July 2002 00:22, William Lee Irwin III wrote:
> As far as operating regions for page replacement go I see 3 obvious ones:
> (1) lots of writeback with no swap
> (2) churning clean pages with no swap
> (3) swapping

Another big variable is the balance of streaming IO versus program workload.
Within streaming IO there is the read/write balance (starting to get away 
from core VM here).  There's also the balance of file cache activity vs
anonymous memory.  It goes on of course - we have to boil this down to a few 
reasonably orthogonal variables.

Your specific load examples can be thought of as specific points in a 
two-dimensional test model with two variables:

  - Total working set relative to physical memory (should range from 
    significantly less to significantly more)

  - Balance of read accesses vs write accesses

Adding up the above, there are 5 knobs to turn so far.  This whole thing 
sounds like it can be modeled elegantly by a couple of C programs, one to 
generate memory loads and another to generate file loads, or we may be able 
to identify an off-the-shelf benchmark program that provides some of the 
tunables we need.

Needless to say, we need more than one or two points on each axis.  We need 
to capture our data in some organized way.  How?

Clearly, this benchmarking project as I've described it is starting to blow 
up into unreasonable dimensions.  I'd like to return to the idea of going 
through the original list of advantages and disadvantages item by item and 
identifying exactly which variables in our complete test space are relevant.  
This lets us set the knobs on our test programs, define the test, and know 
which numbers we want to capture/graph.

-- 
Daniel
--
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/

  parent reply	other threads:[~2002-07-13 14:45 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-09 19:04 [PATCH] Optimize out pte_chain take two Dave McCracken
2002-07-10  0:21 ` Andrew Morton
2002-07-10 14:33   ` [PATCH] Optimize out pte_chain take three Dave McCracken
2002-07-10 15:18     ` Rik van Riel
2002-07-10 17:32       ` William Lee Irwin III
2002-07-10 20:01         ` Andrew Morton
2002-07-10 20:14           ` Rik van Riel
2002-07-10 20:28             ` Andrew Morton
2002-07-10 20:38               ` Rik van Riel
2002-07-13 13:42                 ` Daniel Phillips
2002-07-10 20:33             ` Martin J. Bligh
2002-07-10 22:22           ` William Lee Irwin III
2002-07-11  0:39             ` Andrew Morton
2002-07-11  0:47               ` Rik van Riel
2002-07-11  1:27                 ` Andrew Morton
2002-07-13 14:10                 ` Daniel Phillips
2002-07-11  1:51               ` William Lee Irwin III
2002-07-11  2:28                 ` William Lee Irwin III
2002-07-11 19:54                 ` Andrew Morton
2002-07-11 20:05                   ` Rik van Riel
2002-07-11 20:42                     ` Andrew Morton
2002-07-11 20:54                       ` Rik van Riel
2002-07-11 21:16                         ` Andrew Morton
2002-07-11 21:41                           ` Rik van Riel
2002-07-11 22:38                             ` Andrew Morton
2002-07-11 23:18                               ` Rik van Riel
2002-07-12 18:27                                 ` Paul Larson
2002-07-12 19:06                                   ` Andrew Morton
2002-07-12 19:28                                 ` Andrew Morton
2002-07-13 15:08                               ` Daniel Phillips
2002-07-11 22:54                   ` William Lee Irwin III
2002-07-13 14:52                   ` Daniel Phillips
2002-07-13 14:08               ` Daniel Phillips
2002-07-13 14:20               ` Daniel Phillips
2002-07-13 14:45             ` Daniel Phillips [this message]
2002-07-13 13:22           ` Daniel Phillips
2002-07-13 13:30             ` William Lee Irwin III
2002-07-13 13:55               ` Daniel Phillips
2002-07-13 13:41           ` 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=E17TO9S-0003JO-00@starship \
    --to=phillips@arcor.de \
    --cc=akpm@zip.com.au \
    --cc=dmccr@us.ibm.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=wli@holomorphy.com \
    /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.