[lkml]   [2000]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: mapping user space buffer to kernel address space

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

I've been down that road, and I don't think we want to go there.
Most research shows that fast multiprocessors simply suffer too much
from the TLB shootdown costs to make up for the difference between
copying the page and not copying it. Twiddling with pte's to make them
COW during the I/O is a waste of cycles and it doesn't gain you much
except in the threaded case, in which case the application was brain-dead
to begin with.

Is that what you're suggesting, making the pages COW? Or am I missing
the point?

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

Doesn't incrementing the page count mean we still have the page? I mean,
w/o twiddling with the mapping, the buffer may change while we're doing
I/O on it, but I really don't care if that happens.. if it means I can
avoid 75% of the overhead in the page locking. Since we're not doing
in-place I/O in the general case (e.g. read/write), I think any sane
people can deal with these changed semantics (fbuf-like, that is)

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

Again, because you're adding overhead for the brain-dead semantics.

I think this is Linus' point here -- twiddling with the VM doesn't really
gain you anything at all. The I/O still happens either way, but by
doing it based ONLY on physical pages (as it is now), there's a LOT
less overhead and it still works correctly as long as the application
and driver are well behaved.

And I don't agree that we should ever try to do kiobuf() things in
the read/write general case. I think that mapping files into
kernel buffers and copying the pages to/from the page cache
would suffice, and with the benefit that all page flushing could
then be done through the VM and bdflush eliminated.

Eric Lowe
Software Engineer, Systran Corporation

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