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

[William Lee Irwin III <wli@holomorphy.com>]

On Mon, Mar 22, 2004 at 06:07:56PM -0800, William Lee Irwin III wrote:
>> 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

On Tue, Mar 23, 2004 at 12:35:34PM +0100, Andrea Arcangeli wrote:
> 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.

Hmm. It should move preexisting method calls further up the call chain.
I can't say I have a pressing enough need to pursue it personally
unless it's the way to resolve issues like the one under discussion and
so on. It looks like there's another way that's preferred, so I'm not
looking into it anymore.


On Tue, Mar 23, 2004 at 12:35:34PM +0100, Andrea Arcangeli wrote:
> 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.

mlock actually loops through the fault path, so in a sense it still
requires fault handling on the part of the driver, though AFAICT it can
largely be done by library code. I agree it should be an implementation
detail of dma_mmap_coherent() etc. and pretty much up-front believed
drivers would need code to assist them with fault handling if the did
it, though it didn't originally occur to me that an mmap() function
could install the entire handler on their behalf transparently to them.


-- wli