public inbox for linux-arch@vger.kernel.org
 help / color / mirror / Atom feed
* Re: ZONE_DMA (was: Re: 2.6.19 -mm merge plans)
       [not found]   ` <20060920172253.f6d11445.akpm@osdl.org>
@ 2006-09-21  0:31     ` Christoph Lameter
  2006-09-21  1:03       ` Alan Cox
  0 siblings, 1 reply; 3+ messages in thread
From: Christoph Lameter @ 2006-09-21  0:31 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Martin J. Bligh, linux-kernel, linux-arch, Christoph Hellwig

On Wed, 20 Sep 2006, Andrew Morton wrote:

> > Would it not make sense to define what ZONE_DMA actually means
> > consistently before trying to change it? The current mess across
> > different architectures seems like a disaster area to me.
> > 
> > What DOES requesting ZONE_DMA from a driver actually mean?

ZONE_DMA is a memory area that is needed by an arch for devices that 
cannot do DMA to all of memory. The high boundary is set by 
MAX_DMA_ADDRESS.

> My concern about these patches is that they'll only be useful for
> self-compiled kernels, because distros will be forced to enable ZONE_DMA
> for evermore anyway.

We already have 4 arches now that do not need ZONE_DMA at all.

ZONE_DMA does not have a bright future with IOMMUs and other things 
around. None of my system uses ZONE_DMA and I have a variety of them.

And yes if we do not have this facility in the kernel then distros cannot 
pick it up. At least on IA64 I know that hardware from the major vendors 
has not been needing ZONE_DMA for a while now.

Also ZONE_DMA is a very bad concept. Multiple drivers may have different 
address requirements. What we need is some way for a driver to tell the 
kernel what the required range of addresses is. If a device is only 
capable of handling 30 valid address bits then we may have to use 
ZONE_DMA and only allow the use of the lower 16MB. It would be better to 
develop a different mechanism.



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ZONE_DMA (was: Re: 2.6.19 -mm merge plans)
  2006-09-21  0:31     ` ZONE_DMA (was: Re: 2.6.19 -mm merge plans) Christoph Lameter
@ 2006-09-21  1:03       ` Alan Cox
  2006-09-21 15:59         ` James Bottomley
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Cox @ 2006-09-21  1:03 UTC (permalink / raw)
  To: Christoph Lameter
  Cc: Andrew Morton, Martin J. Bligh, linux-kernel, linux-arch,
	Christoph Hellwig

Ar Mer, 2006-09-20 am 17:31 -0700, ysgrifennodd Christoph Lameter:
> ZONE_DMA does not have a bright future with IOMMUs and other things 
> around. None of my system uses ZONE_DMA and I have a variety of them.

IOMMUs don't always help. They IOMMU aperture on AMD64 for example is
too high to help devices with below 32bit limits.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ZONE_DMA (was: Re: 2.6.19 -mm merge plans)
  2006-09-21  1:03       ` Alan Cox
@ 2006-09-21 15:59         ` James Bottomley
  0 siblings, 0 replies; 3+ messages in thread
From: James Bottomley @ 2006-09-21 15:59 UTC (permalink / raw)
  To: Alan Cox
  Cc: Christoph Lameter, Andrew Morton, Martin J. Bligh, linux-kernel,
	linux-arch, Christoph Hellwig

On Thu, 2006-09-21 at 02:03 +0100, Alan Cox wrote:
> IOMMUs don't always help. They IOMMU aperture on AMD64 for example is
> too high to help devices with below 32bit limits.

That's because it's not an IOMMU; it's a GART.  A true IOMMU separates
the machine physical and bus physical address spaces ... a GART merely
remaps a hole in physical address space.

James



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-09-21 16:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <20060920135438.d7dd362b.akpm@osdl.org>
     [not found] ` <4511D855.7050100@mbligh.org>
     [not found]   ` <20060920172253.f6d11445.akpm@osdl.org>
2006-09-21  0:31     ` ZONE_DMA (was: Re: 2.6.19 -mm merge plans) Christoph Lameter
2006-09-21  1:03       ` Alan Cox
2006-09-21 15:59         ` James Bottomley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox