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

[Andrea Arcangeli <andrea@suse.de>]

On Tue, Mar 23, 2004 at 07:25:31AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 23 Mar 2004, Russell King wrote:
> >
> > On Tue, Mar 23, 2004 at 01:34:39PM +0100, Andrea Arcangeli wrote:
> > > anyways Linus vetoed the lazy approch so we probably should give it up
> > > (the one thing I like most is to avoid the branch in the fast path).
> > 
> > I don't think he did - he vetoed adding another special condition to
> > the fast path, or returning non-RAM pages via ->nopage.
> 
> Indeed.

note that I was talking about non-ram, obviously ram pages can be
returned via ->nopage and that's what drivers are using already.

I know there is a problem with ram pages too, but as far as the ->nopage
API is concerned the only problem are the non-ram pages. Russell's
problem have nothing to do with ->nopage itself.

> What I _don't_ want is top add a new VM op function pointer as a special 
> case. I abhor special cases, since they never go away, and end up making 
> the code really hard to follow.
> 
> > However, I do not believe he has vetoed an architecture implementing
> > dma_coherent_mmap() in such a way that it uses the ->nopage method,
> > _provided_ ->nopage returns valid struct pages.
> 
> Yes. For all I care, the "struct page" migth even be dynamically
> allocated, or something else very special (eg in a zone of its own that

I don't think it's sane to use discontigmem just to make ->nopage work
with non-ram, if one has to use discontigmem just for that then I think
it's much simpler to fill all the pagetables in ->mmap using the pfn w/o
page_t.

> the rest of the VM never ever actually sees). As long as "page_to_pfn()" 

zones cannot create holes in the middle of mem_map, only discontigmem
can. I'd expect in most archs to have holes between ram and mmio
regions (at least in various common ram configuration). That's why I
guess discontigmem would be needed for that.