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: <20070813225020.GE3406@bingen.suse.de>
Date:	Tue, 14 Aug 2007 00:50:20 +0200
From:	Andi Kleen <ak@...e.de>
To:	Christoph Lameter <clameter@....com>
Cc:	Andi Kleen <ak@...e.de>, Mel Gorman <mel@...net.ie>,
	Lee.Schermerhorn@...com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

On Mon, Aug 13, 2007 at 02:25:36PM -0700, Christoph Lameter wrote:
> On Sat, 11 Aug 2007, Andi Kleen wrote:
> 
> > > Hallelujah. You are my hero! x86_64 will switch off CONFIG_ZONE_DMA?
> > 
> > Yes. i386 too actually.
> > 
> > The DMA zone will be still there, but only reachable with special functions.
> 
> Not too happy with that one but this is going the right direcrtion.
> 
> On NUMA this would still mean allocating space for the DMA zone on all 
> nodes although we only need this on node 0.

The DMA allocator is NUMA unaware. This means it doesn't require multiple
dma zones per node, but is happy with a global one that can live somewhere
else outside the pgdat. I also removed PCP and other fanciness so it's
really quite independent and much simpler than the normal one.  It also
doesn't need try_to_free_pages() because in a isolated zone there
shouldn't be any freeable pages.

The big difference is that it can go into a slower than O(1) mode that tries
to find pages based on the DMA mask

> > This also means the DMA support in sl[a-z]b is not needed anymore.
> 
> Tell me when. SLUB has an #ifdef CONFIG_ZONE_DMA. We can just drop that 
> code in the #ifdef's if you are ready.

There are still other architectures that use it. Biggest offender
is s390. I'll leave them to their respective maintainers.

It's not clear s390 really needs the mask allocator anyways.
e.g. I suspect they just need to put data into a specific 
range, but if there are no subranges then it might be
overkill.

-Andi

-
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