Re: can device drivers return non-ram via vm_ops->nopage?

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Mar 22, 2004 at 04:26:29PM +1100, Benjamin Herrenschmidt wrote:
> Well, I just went over this whole discussion and I think it's just
> going to hell.
> 
> So here are my 2 cents of suggestions:
> 
>  - We _WANT_ the ability to map coherent memory to userspace, that's
> the normal way to map sound buffers to userland for low latency (though
> mapping the actual DMA ptrs is a different matter and is definitely not
> working with a bunch of sound interfaces). This is also necessary for
> the infiniband/myrinet kind of things. DRI sort-of need that when not
> using AGP, AGP itself is a special case but could be considered as
> coherent memory in some platforms too (and will be with PCI Express
> afaik) etc...
> 
>  - Some architectures apparently cannot do that (parisc ?)
> 
>  - Too bad for them... They won't have low latency audio and fast
> networking and be done with it. Let's implement a couple of simple
> to use (driver-wise) helpers
> 
>    dma_can_mmap_coherent() -> parisc returns false here
>    dma_mmap_coherent()
>    dma_mmap_coherent_sg()
> 
> And be done with it. I don't see where is the debate here ? The
> API takes the same sglist as used for dma_map_sg, I don't see the
> point of anything different, I agree with linus that it's not worth
> even thinking about not having struct page here. 

I like your three functions and the clear decription.

The only reason I believe a paging mechanism would been nicer, is that
it would avoid latencies in dma_mmap_coherent (not necessairly scheduler
latencies, but you would pay all the cost of the pagetables immediatly
during the mmap syscall, so if you've to map gigs of ram that would tend
to hang the task doing the mmap a little bit, I found it nicer to use
the paging for this so we also only allocate the memory for the
pagetables that we need, but OTOH Linus's right that in most cases it
doesn't worth a single branch in a fast path).