Re: mapping user space buffer to kernel address space

From: Andrea Arcangeli (andrea@suse.de)
Date: Tue Oct 17 2000 - 18:59:49 EST


On Tue, Oct 17, 2000 at 01:02:01PM -0700, Linus Torvalds wrote:
> But what about things like:
> - linearized circular buffers (where "linearized" means that the buffer
> is mapped twice or more consecutively virtually in memory, so that the
> user doesn't need to worry about the boundary conditions that normal
> circular buffers have)

This is exactly the case pointed out by SCT and this should be trivial to
handle just browsing backwards the maplist in the trylock slow path.

> - multiple buffers per page.
>
> And note in particular that you may not be able to page-align everything:
> and it can be extremely costly (both in memory use and in cache footprint)
> to always pad out your buffers etc.

See below for this one.

> It's a simple lookup function, looking up the physical pages that
> correspond to a specific range of virtual memory.
>
> Nothing more.

Yep.

> > 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
>
> If you like it, why do you want to break it?
>
> You _say_ that you like it, but yet you want to add extra conditions like
>
> o while I/O is pending the virtual mapping is fixed

That's not the condition that I want to add. Everybody can do a mremap of the
vma while the I/O runs or as you pointed out everybody can munmap the
virtual memory area while the physical page is referenced by the kiobuf.

What I want to add is basically only:

o swap_out doesn't unmap the pages mapped by a kiobuf from their pte
        and in turn it doesn't swapout them while they could be under I/O

> Are you suggesting something like: if it is reading from a page (ie
> writing the contents of that page somewhere else), we don't lock it, but
> if it is writing to a page, we lock it so that the dirty bit won't get
> lost.

That wasn't what I suggested but I like also the the way you describe above.
It makes sense.

It also seems to handle the case of multiple buffers in the same page.
When we do the pagein (if a pagein is necessary) all users of the page have to
wait anyways. For the pageout they will be able to start writes at the same
time this way.

> Sure, that works (modulo the fact that it still has the issues with
> serializing mmap's and accesses to other areas in the same page). But do
> you really claim that it's the clean solution?

It looks cleaner than swapping out a page while a device is writing
to it in DMA under the swapout.

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/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:12 EST