lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0701291349450.548@schroedinger.engr.sgi.com>
Date:	Mon, 29 Jan 2007 13:54:38 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Andrew Morton <akpm@...l.org>
cc:	Mel Gorman <mel@....ul.ie>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Christoph Lameter <clameter@...r.sgi.com>
Subject: Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between
 movable and non-movable pages

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ