linux-kernel - Re: [PATCH 3/4] Embed zone_id information within the zonelist->zones pointer

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]

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/