Messages in this thread | | | Date | Wed, 18 Oct 2000 09:39:39 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: mapping user space buffer to kernel address space |
| |
On Wed, 18 Oct 2000, Andrea Arcangeli wrote: > > > Quite frankly, the way I'd conceptually prefer people do these kinds of > > DMA buffers etc is to just have a "nopage()" function, and let that > > nopage() function just fill in the page from the DMA buffer directly. This > > would work fine, and would get rid of all the playing with PG_reserved > > etc. > > And it would generate useless page faults as well. What's the point > of unmapping a page that can't be freed? Once the page gets freed > the mapping just gone away via munmap anyways. What's the point of > introducing that performance hit?
As I explained in the part you snipped, this is why I _do_ accept remap_page_range().
But to answer your question: the point is cleanliness.
For example, remap_page_range() cannot do many things. Because a reserved page does not maintain any counts (that's the definition of "reserved" as far as the Linux MM is concerned - the pages never count anything), you cannot do proper memory management with it.
In the specific case of braindead hardware that needs a 1:1 direct mapping due to DMA limitations etc, that's exactly what you want. You can't let people move pages around anyway or do things like that. You can never let people swap these pages out, because there is no point.
But this is NOT how the MM layer should work in general. And it's sure as h*ll not how the direct IO layer is going to work. You can argue until you get blue in the face, I don't care. I'm _not_ going to accept some braindamaged setup where you can only have one concurrent write into a page at the same time. I'm _not_ going to accept some braindamaged setup where you can't unmap such a page in another process or thread.
In short, I'm _not_ willing to paper over bugs by just saying "don't touch this page".
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |