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

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Mar 22, 2004 at 06:07:56PM -0800, William Lee Irwin III wrote:
> On Mon, Mar 22, 2004 at 05:18:30PM -0500, Jeff Garzik wrote:
> >> This is burned into silicon, so supporting it's not an option. Frankly
> >> I think what's best is another device interface for userspace to fall
> >> back to when this coherent userspace mmap() is unimplementable, e.g.
> >> read()/write() on some device node.
> 
> On Tue, Mar 23, 2004 at 10:57:19AM +1100, Benjamin Herrenschmidt wrote:
> > Exactly. We can implement the simple/nice interface discussed here, and
> > just not support it on those platforms, they'll have to fall back to
> > read/write or simply not support those drivers who require that
> > functionality.
> > Eventually a nopage variant may be worth for things doing really
> > large mappings, but I tend to think that when we need to do that mapping
> > to userland, it is because we need short latencies, which is the opposite
> > of what a nopage implementation provides, dunno if it's worth the pain
> > (though it's not _that_ painful).
> 
> More generality in fault handling would be useful in various ways even
> beyond fixing ALSA's issues. I'm not sure why Linus doesn't like the
> notion. I didn't insist on API but just moved on to trying to push for

my guess is that he doesn't like a branch in the fast path and he thinks
remap_file_pages approch is simpler for drivers to use.

as for the initial page fault mentioned by Benjamin, that's a non issue,
if one prefers to preallocate all the ptes thank to take a page fault
the very first time the pages are touched, I already said some email ago
that one can call mlock on the mapping and there will be not a single
page fault anymore afterwards.