LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Christoph Lameter <clameter@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Mel Gorman <mel@csn.ul.ie>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Christoph Lameter <clameter@engr.sgi.com>
Subject: Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages
Date: Mon, 29 Jan 2007 13:54:38 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701291349450.548@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20070126122747.dde74c97.akpm@osdl.org>

On Fri, 26 Jan 2007, Andrew Morton wrote:

> > The main benefit is a significant simplification of the VM, leading to 
> > robust and reliable operations and a reduction of the maintenance 
> > headaches coming with the additional zones.
> > 
> > If we would introduce the ability of allocating from a range of 
> > physical addresses then the need for DMA zones would go away allowing 
> > flexibility for device driver DMA allocations and at the same time we get 
> > rid of special casing in the VM.
> 
> None of this is valid.  The great majority of machines out there will
> continue to have the same number of zones.  Nothing changes.

All 64 bit machine will only have a single zone if we have such a range 
alloc mechanism. The 32bit ones with HIGHMEM wont be able to avoid it, 
true. But all arches that do not need gymnastics to access their memory 
will be able run with a single zone.
 
> That's all a real cost, so we need to see *good* benefits to outweigh that
> cost.  Thus far I don't think we've seen that.

The real savings is the simplicity of VM design, robustness and 
efficiency. We loose on all these fronts if we keep or add useless zones. 

The main reason for the recent problems with dirty handling seem to be due 
to exactly such a multizone balancing issues involving ZONE_NORMAL and 
HIGHMEM. Those problems cannot occur on single ZONE arches (this means 
right now on a series of embedded arches, UML and IA64). 

Multiple ZONES are a recipie for VM fragility and result in complexity 
that is difficult to manage.

  reply	other threads:[~2007-01-29 21:54 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 23:44 Mel Gorman
2007-01-25 23:45 ` [PATCH 1/8] Add __GFP_MOVABLE for callers to flag allocations that may be migrated Mel Gorman
2007-01-26 12:27   ` Nick Piggin
2007-01-26 13:25     ` Mel Gorman
2007-01-25 23:45 ` [PATCH 2/8] Create the ZONE_MOVABLE zone Mel Gorman
2007-01-26 16:28   ` Christoph Lameter
2007-01-26 16:49     ` Mel Gorman
2007-01-29 17:28     ` Mel Gorman
2007-01-26 17:16   ` Christoph Lameter
2007-01-26 17:24     ` Mel Gorman
2007-01-26 17:25       ` Christoph Lameter
2007-01-26 17:38         ` Mel Gorman
2007-01-29 17:31     ` Mel Gorman
2007-01-25 23:45 ` [PATCH 3/8] Allow huge page allocations to use GFP_HIGH_MOVABLE Mel Gorman
2007-01-26 16:33   ` Christoph Lameter
2007-01-26 16:58     ` Mel Gorman
2007-01-26 17:04       ` Christoph Lameter
2007-01-26 17:20         ` Mel Gorman
2007-01-26 17:22           ` Christoph Lameter
2007-01-26 17:37             ` Mel Gorman
2007-01-26 17:45               ` Christoph Lameter
2007-01-26 17:53                 ` Mel Gorman
2007-01-26 18:20                   ` Christoph Lameter
2007-01-26 20:37                     ` Mel Gorman
2007-01-26 18:35                   ` Chris Friesen
2007-01-26 20:44                     ` Mel Gorman
2007-01-26 21:37                       ` Chris Friesen
2007-01-25 23:46 ` [PATCH 4/8] x86 - Specify amount of kernel memory at boot time Mel Gorman
2007-01-25 23:46 ` [PATCH 5/8] ppc and powerpc " Mel Gorman
2007-01-25 23:46 ` [PATCH 6/8] x86_64 " Mel Gorman
2007-01-25 23:47 ` [PATCH 7/8] ia64 " Mel Gorman
2007-01-25 23:47 ` [PATCH 8/8] Add documentation for additional boot parameter and sysctl Mel Gorman
2007-01-26 11:07 ` [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages Andrew Morton
2007-01-26 14:29   ` Mel Gorman
2007-01-26 16:01     ` Christoph Lameter
2007-01-26 15:56   ` Christoph Lameter
2007-01-26 19:46     ` Andrew Morton
2007-01-26 19:58       ` Christoph Lameter
2007-01-26 20:27         ` Andrew Morton
2007-01-29 21:54           ` Christoph Lameter [this message]
2007-01-29 22:36             ` Andrew Morton
2007-01-29 22:45               ` Christoph Lameter
2007-01-29 22:50                 ` Russell King
2007-01-29 23:37                   ` Christoph Lameter
2007-01-30  0:09                     ` Andrew Morton
2007-01-30  9:53                       ` Peter Zijlstra
2007-02-02  5:27                         ` Christoph Lameter
2007-02-02  5:22                       ` Christoph Lameter
2007-01-26 16:21 ` Christoph Lameter
2007-01-26 16:48   ` Mel Gorman
2007-01-26 17:02     ` Christoph Lameter
2007-01-26 17:20       ` Mel Gorman

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=Pine.LNX.4.64.0701291349450.548@schroedinger.engr.sgi.com \
    --to=clameter@sgi.com \
    --cc=akpm@osdl.org \
    --cc=clameter@engr.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --subject='Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages' \
    /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

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).