Re: [PATCH 2/2] Remove dma_coherent_mem interface

[Matthew Wilcox <matthew@wil.cx>]

On Tue, Oct 30, 2007 at 03:26:31PM -0500, James Bottomley wrote:
> Its design was basically to facilitate the use of bus remote memory.
> There's a long thread somewhere discussing this with the ARM people.
> They had some type of SoC implementation that needed to allocate local
> memory for device descriptors.  The Q720 is pretty much the same way, so
> I used it to build the implementation when I created it for the ARM
> people.  This is the original thread:
> 
> http://marc.info/?t=108757862100001
> 
> They said they were implementing this system, so I've no idea what
> happened.

It's been over three years, and it hasn't happened.

> However, what are the problems the API is causing?  it seems
> useful, so there should be a preference in its favour of existence
> unless it's causing a problem.

What I'm currently looking at is the dmapool allocator.  It's not
exactly fast (a spinlock for each allocation ... no concept of cpu
affinity, etc), and some drivers (eg qla2xxx) use it in the performance
path.

One of the suggestions in the existing dmapool driver is to share the
guts of slab.  Well, slab is probably going away, so I took a look
at slub.  Slub really, *really* needs the struct page associated
with the page of memory allocated, so I'm currently working my way
through the architectures trying to turn dma_alloc_coherent into
dma_alloc_coherent_pages.

The dma_coherent_mem API is one of the things which gets in the way of
doing this.  So I deleted it, then sent the patch out for comments early.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."