[lkml]   [2000]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

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".


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.141 / U:1.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site