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

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