Re: ZONE_DMA
From: Martin Bligh
Date: Thu Sep 21 2006 - 12:57:37 EST
Christoph Lameter wrote:
On Wed, 20 Sep 2006, Martin J. Bligh wrote:
ZONE_DMA is only used as ZONE_NORMAL if the architecture does not need
ZONE_NORMAL because all of memory is reachable via DMA.
That's still inconsistent because it doesn't say DMA for *which*
device.
Thats the way ZONE_DMA works right now and AFAIK the only way forward is
to make it optional and then introduce another way of allocating memory
for a device. The migrate away from it. The first step is to allow people
who do not need ZONE_DMA to opt out.
OK. Let's leave aside the issue for a second of whether ZONE_DMA should
be configurable or not (ie your patch), and just worry about how this
works in practice going forwards in the short term. Don't get me wrong,
I'd love to kill ZONE_DMA, or at least the 16MB way it's implemented in
i386 right now.
I presume the fallback order for everything is still
HIGHMEM -> NORMAL -> DMA, and nobody is proposing changing that.
(ignoring DMA32 to keep thing simpler).
If a device driver wants "DMAable" memory, and thus does a ZONE_DMA
allocation, and we've moved all its memory from ZONE_DMA to ZONE_NORMAL
(as I think you're proposing doing for PPC64 (and ia64?)), then the
allocation will fail.
So are we saying that no driver code should be calling with GFP_DMA
(a quick grep turns up 148 instances under driver/), that if they do
they should only work on specific architectures (some instances were
s390-only drivers)? If so, should we not be removing the definiton of
GFP_DMA itself if ZONE_DMA is config'ed out, so that it fails at
compile time, rather than runtime?
AFAICS, the correct way to do this is have the requestor pass a memory
bound into the allocator, and have the arch figure out which zones
are applicable.
Exactly. But you cannot do that with ZONE_DMA __GFP_DMA. We likely need a
new page allocator API for that.
Glad we're agreed on that, at least.
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/