All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Magnus Damm <magnus@valinux.co.jp>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: [PATCH 00/03] Unmapped: Separate unmapped and mapped pages
Date: Fri, 10 Mar 2006 15:55:37 +1100	[thread overview]
Message-ID: <441106C9.9040502@yahoo.com.au> (raw)
In-Reply-To: <20060310034412.8340.90939.sendpatchset@cherry.local>

Magnus Damm wrote:
> Unmapped patches - Use two LRU:s per zone.
> 
> These patches break out the per-zone LRU into two separate LRU:s - one for
> mapped pages and one for unmapped pages. The patches also introduce guarantee 
> support, which allows the user to set how many percent of all pages per node
> that should be kept in memory for mapped or unmapped pages. This guarantee 
> makes it possible to adjust the VM behaviour depending on the workload.
> 
> Reasons behind the LRU separation:
> 
> - Avoid unnecessary page scanning.
>   The current VM implementation rotates mapped pages on the active list
>   until the number of mapped pages are high enough to start unmap and page out.
>   By using two LRU:s we can avoid this scanning and shrink/rotate unmapped 
>   pages only, not touching mapped pages until the threshold is reached.
> 
> - Make it possible to adjust the VM behaviour.
>   In some cases the user might want to guarantee that a certain amount of 
>   pages should be kept in memory, overriding the standard behaviour. Separating
>   pages into mapped and unmapped LRU:s allows guarantee with low overhead.
> 
> I've performed many tests on a Dual PIII machine while varying the amount of
> RAM available. Kernel compiles on a 64MB configuration gets a small speedup, 
> but the impact on other configurations and workloads seems to be unaffected.
> 
> Apply on top of 2.6.16-rc5.
> 
> Comments?
> 

I did something similar a while back which I called split active lists.
I think it is a good idea in general and I did see fairly large speedups
with heavy swapping kbuilds, but nobody else seemed to want it :P

So you split the inactive list as well - that's going to be a bit of
change in behaviour and I'm not sure whether you gain anything.

I don't think PageMapped is a very good name for the flag.

I test mapped lazily. Much better way to go IMO.

I had further patches that got rid of reclaim_mapped completely while
I was there. It is based on crazy metrics that basically completely
change meaning if there are changes in the memory configuration of
the system, or small changes in reclaim algorithms.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Magnus Damm <magnus@valinux.co.jp>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: [PATCH 00/03] Unmapped: Separate unmapped and mapped pages
Date: Fri, 10 Mar 2006 15:55:37 +1100	[thread overview]
Message-ID: <441106C9.9040502@yahoo.com.au> (raw)
In-Reply-To: <20060310034412.8340.90939.sendpatchset@cherry.local>

Magnus Damm wrote:
> Unmapped patches - Use two LRU:s per zone.
> 
> These patches break out the per-zone LRU into two separate LRU:s - one for
> mapped pages and one for unmapped pages. The patches also introduce guarantee 
> support, which allows the user to set how many percent of all pages per node
> that should be kept in memory for mapped or unmapped pages. This guarantee 
> makes it possible to adjust the VM behaviour depending on the workload.
> 
> Reasons behind the LRU separation:
> 
> - Avoid unnecessary page scanning.
>   The current VM implementation rotates mapped pages on the active list
>   until the number of mapped pages are high enough to start unmap and page out.
>   By using two LRU:s we can avoid this scanning and shrink/rotate unmapped 
>   pages only, not touching mapped pages until the threshold is reached.
> 
> - Make it possible to adjust the VM behaviour.
>   In some cases the user might want to guarantee that a certain amount of 
>   pages should be kept in memory, overriding the standard behaviour. Separating
>   pages into mapped and unmapped LRU:s allows guarantee with low overhead.
> 
> I've performed many tests on a Dual PIII machine while varying the amount of
> RAM available. Kernel compiles on a 64MB configuration gets a small speedup, 
> but the impact on other configurations and workloads seems to be unaffected.
> 
> Apply on top of 2.6.16-rc5.
> 
> Comments?
> 

I did something similar a while back which I called split active lists.
I think it is a good idea in general and I did see fairly large speedups
with heavy swapping kbuilds, but nobody else seemed to want it :P

So you split the inactive list as well - that's going to be a bit of
change in behaviour and I'm not sure whether you gain anything.

I don't think PageMapped is a very good name for the flag.

I test mapped lazily. Much better way to go IMO.

I had further patches that got rid of reclaim_mapped completely while
I was there. It is based on crazy metrics that basically completely
change meaning if there are changes in the memory configuration of
the system, or small changes in reclaim algorithms.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2006-03-10  4:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-10  3:44 [PATCH 00/03] Unmapped: Separate unmapped and mapped pages Magnus Damm
2006-03-10  3:44 ` Magnus Damm
2006-03-10  3:44 ` [PATCH 01/03] Unmapped: Implement two LRU:s Magnus Damm
2006-03-10  3:44   ` Magnus Damm
2006-03-10 19:16   ` Christoph Lameter
2006-03-10 19:16     ` Christoph Lameter
2006-03-11 12:14     ` Magnus Damm
2006-03-11 12:14       ` Magnus Damm
2006-03-10  3:44 ` [PATCH 02/03] Unmapped: Modify LRU behaviour Magnus Damm
2006-03-10  3:44   ` Magnus Damm
2006-03-10  3:44 ` [PATCH 03/03] Unmapped: Add guarantee code Magnus Damm
2006-03-10  3:44   ` Magnus Damm
2006-03-10  4:57   ` Nick Piggin
2006-03-10  4:57     ` Nick Piggin
2006-03-10  6:04     ` Magnus Damm
2006-03-10  6:04       ` Magnus Damm
2006-03-10 15:41       ` Chandra Seetharaman
2006-03-10 15:41         ` Chandra Seetharaman
2006-03-11 12:29         ` Magnus Damm
2006-03-11 12:29           ` Magnus Damm
2006-03-15 15:32           ` Chandra Seetharaman
2006-03-15 15:32             ` Chandra Seetharaman
2006-03-10  4:55 ` Nick Piggin [this message]
2006-03-10  4:55   ` [PATCH 00/03] Unmapped: Separate unmapped and mapped pages Nick Piggin
2006-03-10  5:55   ` Magnus Damm
2006-03-10  5:55     ` Magnus Damm
2006-03-10  7:52 ` Arjan van de Ven
2006-03-10  7:52   ` Arjan van de Ven
2006-03-10 13:19   ` Magnus Damm
2006-03-10 13:19     ` Magnus Damm
2006-03-10 14:05     ` Arjan van de Ven
2006-03-10 14:05       ` Arjan van de Ven
2006-03-11 11:52       ` Magnus Damm
2006-03-11 11:52         ` Magnus Damm
2006-03-11 20:58     ` Peter Zijlstra
2006-03-11 20:58       ` Peter Zijlstra
2006-03-13  2:28       ` Magnus Damm
2006-03-13  2:28         ` Magnus Damm
2006-03-10 12:22 ` Peter Zijlstra
2006-03-10 12:22   ` Peter Zijlstra
2006-03-10 13:38   ` Magnus Damm
2006-03-10 13:38     ` Magnus Damm
2006-03-11 21:08     ` Peter Zijlstra
2006-03-11 21:08       ` Peter Zijlstra
2006-03-13  3:05       ` Magnus Damm
2006-03-13  3:05         ` Magnus Damm
2006-03-10 19:12 ` Christoph Lameter
2006-03-10 19:12   ` Christoph Lameter
2006-03-11 11:56   ` Magnus Damm
2006-03-11 11:56     ` Magnus Damm

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=441106C9.9040502@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=magnus@valinux.co.jp \
    /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.