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, 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?

Yeah. I thought so.

Bye, bye, performance. You might as well remove the whole thing
completely.

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
confuse virtual addresses into this, because the thing should be usable
even in the complete absense of virtual mappings (ie the kernel can do
direct IO purely based on pages - think sendfile() etc).

What does this mean? It means that the notion of writing directly from
user space doesn't actually exist in the Linux implementation of direct IO
at all. What Linux direct IO does is really a two-phase operation:

- look up the physical pages.
- do IO based on physical pages

The two are completely and entirely unrelated. Think "good design". Think
"modularity". Think "containment".

Which means, btw, that "virtual pinning" does not make sense from a
conceptual standpoint at all. Because the "virtual" part does not even
_exist_ by the time we do IO.

> The only "problematic" case that I can see is the one mentioned by SCT that is
> the same physical page present in two entries of the maplist in the kiobuf (in
> my patch the user_map_kiobuf will return -EINVAL gracefully in that case and
> that behaviour doesn't look horribly wrong to me). And that case can be
> trivially handled by checking the list backwards in the trylock slowpath as I
> just said.

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

Your bug is a non-issue: it can obviously be fixed other ways, and has
nothing to do with virtually pinning the page. Yes, pinning the page in
the virtual map would also fix it, but at the cost of completely breaking
the whole idea of what direct IO is all about.

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