linux-kernel - Re: [PATCH 0/8] Create ZONE_MOVABLE to partition memory between movable and non-movable pages

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: <20070129225000.GG6602@flint.arm.linux.org.uk>
Date:	Mon, 29 Jan 2007 22:50:01 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Christoph Lameter <clameter@....com>
Cc:	Andrew Morton <akpm@...l.org>, 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 Mon, Jan 29, 2007 at 02:45:06PM -0800, Christoph Lameter wrote:
> On Mon, 29 Jan 2007, Andrew Morton wrote:
> 
> > > 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.
> > 
> > What is "such a range alloc mechanism"?
> 
> As I mentioned above: A function that allows an allocation to specify 
> which physical memory ranges are permitted.
> 
> > So please stop telling me what a wonderful world it is to not have multiple
> > zones.  It just isn't going to happen for a long long time.  The
> > multiple-zone kernel is the case we need to care about most by a very large
> > margin indeed.  Single-zone is an infinitesimal corner-case.
> 
> We can still reduce the number of zones for those that require highmem to 
> two which may allows us to avoid ZONE_DMA/DMA32 issues  and allow dma 
> devices to avoid bunce buffers that can do I/O to memory ranges not 
> compatible with the current boundaries of DMA/DMA32. And I am also 
> repeating myself.

This sounds like it could help ARM where we have some weird DMA areas.

What will help even more is if the block layer can also be persuaded that
a device dma mask is precisely that - a mask - and not a set of leading
ones followed by a set of zeros, then we could eliminate the really ugly
dmabounce code.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/