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

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