lkml.org 
[lkml]   [2000]   [Oct]   [17]   [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 Tue, Oct 17, 2000 at 11:36:22AM -0700, Linus Torvalds wrote:
    > On Tue, 17 Oct 2000, Andrea Arcangeli wrote:
    > >
    > > > Andrea, explain to me how pinning _could_ work? Explain to me how you'd
    > > > lock down pages in virtual address space with multiple threads, and how
    > > > you'd handle the cases of:
    > > >
    > > > - two threads doing direct IO from different parts of the same page
    > > > - one thread starting IO from a page, another thread unmapping the range
    > >
    > > I don't see the problem with those two cases.
    > >
    > > In the first case the first task will sleep in wait_on_page until the
    > > second task will unmap the kiobuf.
    >
    > Ehh.. Remind me again what the whole _point_ of physical IO was, in the
    > first place?
    >
    > Was it maybe PERFORMANCE?

    It should certainly run fast :).

    > Yeah. I thought so.
    >
    > Bye, bye, performance. You might as well remove the whole thing
    > completely.

    I don't think that is a common case relevant for performance. I seen it only as
    a case that we must handle without losing stability.

    For example if both threads are reading different part of disk using the same
    buffer that's also a wrong condition that will provide impredictable result (or
    if they're reading the same part of disk why are they doing it twice?). If both
    threads are writing to different part of disk using the same buffer then you're
    right we could push more I/O at the same time by avoiding the locked bit but
    that case doesn't look very interesting to me.

    > Also, note that one of my requirements to accept the direct IO patches in
    > the first place from Stephen was that I wanted them to NOT mess at all
    > with virtual memory mappings. Basically, the way kio buffers work is that
    > they are 100% based on only physical pages. There are no virtual issues at
    > all in the IO, and that's exactly how I want it. There is no reason to

    That's kiobuf.

    Example: we use kiobuf to handle COWs in the LVM snapshotting code. That only
    deals with physical pages. It never walks pagetables. It never cares about the
    VM. Those pages never become visible from userspace. All right.

    But in map_user_kiobuf we can't avoid to play with the virtual memory,
    as we can't avoid to do that in the remap_page_range case.

    > conceptual standpoint at all. Because the "virtual" part does not even
    > _exist_ by the time we do IO.

    The fact is that the "virtual" part _exists_ since the page that we are doing
    I/O from/to is mapped in the virtual address of the task and so the VM will play
    with it from under us.

    > And WHY do you want to pin the damn things virtually in the first place?

    In short for the same reason all drivers mapping in userspace kernel memory
    via remap_page_range are first calling mem_map_reserve on the physical
    page.

    Why should we make the VM and rawio more complex when we can simply pin the
    page in the pte as mem_map_reserve always did so far? I can see the fact you
    can't write to two different part of disk the same buffer from two threads at
    the same time but that looks a non interesting case and if we need to optimize
    it I'd prefer to do it in another way than to put further VM stuff into rawio.

    In fact the reason I don't like to put VM stuff into rawio is that I like
    the clean design that you described:

    o lookup the physical page
    o do I/O on the physical page

    and not:

    o lookup the physical page
    o do I/O on the physical page
    o check what the physical page become, if it's swap cache
    the set this bit, otherwise set this other bit and then
    the VM will write us to disk again later because we put
    some more check in the VM to handle us

    Andrea
    -
    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:2.311 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site