Re: ZONE_DMA

[Jesse Barnes]

On Thursday, September 21, 2006 7:59 pm, Christoph Lameter wrote:
> > So if you just put all of memory in ZONE_DMA for your particular
> > machine, and bumped the DMA limit up to infinity, we wouldn't need
> > any of these patches, right? Which would also match what the other
> > arches do for this (eg PPC64).

This is what Altix did for a long time (and it looks like it still sets 
MAX_DMA_ADDRESS to the top of addressable memory).

> That would mean abusing ZONE_DMA for a purpose it was not intended for.
> ZOME_DMA is used to partition memory for a DMA not for covering all of
> memory. That works yes but it shows a misunderstanding of the purpose
> for which ZONE_DMA was created.

AFAIK ZONE_DMA was created for crappy ISA devices that could only DMA to 
low addresses.  As various architectures were added, they either 
misunderstood its purpose, abused it for their own purposes, or ignored it 
in some way as it didn't really apply.

> ZONE_NORMAL is DMAable. GFP_DMA has never meant this is for DMA but it
> has always meant this is for a special restricted DMA zone. That is also
> why you have GFP_DMA32. Both GFP_DMA and GFP_DMA32 select special
> restricted memory areas for handicapped DMA devices that are not able to
> reach all of memory. Neither should cover all of memory.

If you have a decent enough IOMMU both or either could cover all of memory.  
In the case of an Altix, the IOMMU is 32 bit capable, so it would make 
sense for ZONE_DMA32 to contain all of memory...

But anyway, I agree with your broader point that we really need a different 
allocator for this stuff.  It has to be arch specific in some way though, 
so we can take into account the advantages IOMMUs provide.  I think jejb 
said he'd come up with a sample implementation a couple of years ago... :)

>From a portability and definition perspective, I'd contend that ZONE_DMA 
and ZONE_DMA32 are both broken.  Only ZONE_NORMAL and ZONE_HIGHMEM have 
sane definitions it seems.

Jesse
-
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/