Andrea Arcangeli wrote:
>
> On Fri, Oct 20, 2000 at 02:19:59PM -0400, Jeff Garzik wrote:
> > Why? [..]
>
> vma information isn't passed from v4l layer to lowlevel layer.
so I see :(
The Matrox Meteor II driver I'm developing uses DMA memory, PCI shared
memory, -or- reserve_bootmem memory in mm
On Fri, Oct 20, 2000 at 02:19:59PM -0400, Jeff Garzik wrote:
> Why? [..]
vma information isn't passed from v4l layer to lowlevel layer.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www
On Fri, 20 Oct 2000, Jeff Garzik wrote:
>
> If I understand your patch, I should call vma_reserve(), and then
> completely remove my no-op swapout(). Correct?
Note that I dislike "wrapper.h", and I just removed that part.
I don't think it's any clearer to write "vma_reserve(vma)" than it is
Andrea Arcangeli wrote:
> On Fri, Oct 20, 2000 at 01:46:53PM -0400, Jeff Garzik wrote:
> > In any case, we shouldn't modify videodev.c to call vma_reserve()...
> > Let the driver's mmap operation do that or not do that, as it chooses.
>
> It can't with the current mmap video4linux kernel API.
Wh
Hi,
On Tue, Oct 17, 2000 at 09:42:36PM -0700, Linus Torvalds wrote:
> Now, the way I'v ealways envisioned this to work is that the VM scanning
> function basically always does the equivalent of just
>
> - get PTE entry, clear it out.
> - if PTE was dirty, add the page to the swap cache, and m
In article <[EMAIL PROTECTED]>,
you write:
>
>
>On Thu, 19 Oct 2000, Jeff Garzik wrote:
>>
>> I stole the last two lines from drivers/char/drm/vm.c, which might need
>> to be fixed up also.. He uses the vm_flags above and nevers calls
>> get_page, at the very least.
>
>The DRM code does
>
>
On Fri, Oct 20, 2000 at 01:46:53PM -0400, Jeff Garzik wrote:
> In any case, we shouldn't modify videodev.c to call vma_reserve()...
> Let the driver's mmap operation do that or not do that, as it chooses.
It can't with the current mmap video4linux kernel API.
In practice it doesn't matter becau
On Fri, Oct 20, 2000 at 10:44:40AM -0700, Linus Torvalds wrote:
> agree with your change, but I just suspect it will break drivers that have
you're right, it would break it, the driver should really somehow increase the
pagecount for each mapping with the PG_reserved removed (in the future that c
Andrea Arcangeli wrote:
> > As to your rvmalloc()/rvfree() changes, I don't think they are safe as-is:
> > I think it's the right thing to do, but I don't trust the drivers to
> > maintain the right page counts. The code used to mark the pages as
> > reserved, which probably means that it hides ba
On Thu, 19 Oct 2000, Stephen Tweedie wrote:
> >
> > Then, we'd move the "writeout" part into the LRU queue side, and at that
> > point I agree with you 100% that we probably should just delay it until
> > there are no mappings available
>
> I've just been talking about this with Ben LaHaise an
On Fri, Oct 20, 2000 at 10:10:05AM -0700, Linus Torvalds wrote:
> Sure. I have no problem at all with this suggestion: it's basically just a
> hint to the VM layer that trying to page something out in this vma is
> useless, as its backing store is in memory anyway.
Yes, that is _exactly_ the poin
On Thu, Oct 19, 2000 at 03:45:43PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 20 Oct 2000, Andrea Arcangeli wrote:
>
> > On Thu, Oct 19, 2000 at 05:16:14PM -0400, Jeff Garzik wrote:
> > > solution is really elegant. Excluding all the debug code and assertions
> > > I stick in there, the guts o
Andrea Arcangeli wrote:
>
> On Thu, Oct 19, 2000 at 05:16:14PM -0400, Jeff Garzik wrote:
> > solution is really elegant. Excluding all the debug code and assertions
> > I stick in there, the guts of via audio mmap support went from ~50 lines
> > to ~10.
>
> Was it 50 lines with remap_page_range
On Fri, 20 Oct 2000, Andrea Arcangeli wrote:
> On Thu, Oct 19, 2000 at 05:16:14PM -0400, Jeff Garzik wrote:
> > solution is really elegant. Excluding all the debug code and assertions
> > I stick in there, the guts of via audio mmap support went from ~50 lines
> > to ~10.
>
> Was it 50 lines
On Thu, 19 Oct 2000, Jeff Garzik wrote:
>
> I stole the last two lines from drivers/char/drm/vm.c, which might need
> to be fixed up also.. He uses the vm_flags above and nevers calls
> get_page, at the very least.
The DRM code does
atomic_inc(&virt_to_page(physical)->count);
which i
On Thu, Oct 19, 2000 at 05:16:14PM -0400, Jeff Garzik wrote:
> solution is really elegant. Excluding all the debug code and assertions
> I stick in there, the guts of via audio mmap support went from ~50 lines
> to ~10.
Was it 50 lines with remap_page_range?
Which is the advantage of introducin
Linus Torvalds wrote:
> and quite frankly we should just change the damn "nopage()" arguments to
> be
>
> struct page * (*nopage)(struct vm_area_struct * area, unsigned long pgoff,
>int write_access);
>
> because the nopage() routine really shouldn't care about "address" at all
> (the V
On Thu, 19 Oct 2000, Jeff Garzik wrote:
>
> > > Since this code works in my local tests, my two concerns at this point
> > > are correct vma->vm_pgoff treatment, and correct vm_flags/vm_file usage.
>
> Can I completely ignore vm_pgoff in nopage()? Currently I just do the
> following, to get t
Linus Torvalds wrote:
> Looks reasonable - although your "max_size" checks are wrong at mmap time.
> You should check for something like
thanks
> > Since this code works in my local tests, my two concerns at this point
> > are correct vma->vm_pgoff treatment, and correct vm_flags/vm_file usage.
On Wed, 18 Oct 2000, Jeff Garzik wrote:
>
> Well coolio. Would somebody be up for sanity checking my audio mmap
> code (attached)? It doesn't look too hard at all to get the audio
> drivers doing the correct thing.
Looks reasonable - although your "max_size" checks are wrong at mmap time.
Yo
On Wed, Oct 18, 2000 at 10:30:45PM -0400, Jeff Garzik wrote:
> Well coolio. Would somebody be up for sanity checking my audio mmap
> code (attached)? It doesn't look too hard at all to get the audio
Nice patch ;).
> vma->vm_flags |= VM_LOCKED | VM_SHM; /* Don't swap */
Since you do vm_
Linus Torvalds wrote:
> Anyway, I didn't realize you were talking about the sound drivers use of
> remap_page_range(). That's not the original reason for remap_page_range()
> at all, and in fact it's the _ugly_ way to do things. It's simple and it
> works, but it's not pretty.
>
> Quite frankly,
> I've got kiobuf diffs which allow you to (a) map any kernel memory
> (including vmalloced areas) into a kiobuf, and then (b) mmap any
> kiobuf into user space using sane, faulting vmas (with the option of
> prefaulting for performance if you want it). Nobody is using it right
> now so I wasn't
On Wed, 18 Oct 2000, Andrea Arcangeli wrote:
>
> > Quite frankly, the way I'd conceptually prefer people do these kinds of
> > DMA buffers etc is to just have a "nopage()" function, and let that
> > nopage() function just fill in the page from the DMA buffer directly. This
> > would work fine,
On Wed, Oct 18, 2000 at 03:40:39PM +0100, Stephen C. Tweedie wrote:
> shm already does it: [..]
Right. Only the shared mappings and anonymoys memory need to be changed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Hi,
On Wed, Oct 18, 2000 at 03:23:17PM +0200, Andrea Arcangeli wrote:
> This change makes sense and I agree it would cover the problem. However I
> prefer to clarify that doing it for the swap cache as described is not nearly
> enough to cover the mm corruption (everything that gets written via
Hi,
On Tue, Oct 17, 2000 at 09:26:07PM -0700, Linus Torvalds wrote:
> I hated people mis-using it the way it's being done by the sound drivers,
> but because I also realize that it allows for some simplifications I do
> accept it - it's basically an ugly hack that doesn't really matter because
>
On Tue, Oct 17, 2000 at 09:42:36PM -0700, Linus Torvalds wrote:
> - get PTE entry, clear it out.
> - if PTE was dirty, add the page to the swap cache, and mark it dirty,
>but DON'T ACTUALLY START THE IO!
> - free the page.
>
> Basically, we removed the page from the virtual mapping, and it
On Tue, Oct 17, 2000 at 09:26:07PM -0700, Linus Torvalds wrote:
> Maybe you mean PG_reserved?
Yes of course. (sorry for the typo)
> Quite frankly, the way I'd conceptually prefer people do these kinds of
> DMA buffers etc is to just have a "nopage()" function, and let that
> nopage() function j
On Wed, 18 Oct 2000, Andrea Arcangeli wrote:
>
> > 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
On Wed, 18 Oct 2000, Andrea Arcangeli wrote:
> On Tue, Oct 17, 2000 at 02:04:10PM -0700, Linus Torvalds wrote:
> > It so happens that the vmscan stuff won't ever remove a physical page
> > mapping, but that's simply because such a page CANNOT be swapped out. How
>
> So if I write a mechanism t
Hi,
On Wed, Oct 18, 2000 at 01:00:48AM +0200, Andrea Arcangeli wrote:
> On Tue, Oct 17, 2000 at 02:04:10PM -0700, Linus Torvalds wrote:
> > It so happens that the vmscan stuff won't ever remove a physical page
> > mapping, but that's simply because such a page CANNOT be swapped out. How
>
> So i
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 co
On Tue, Oct 17, 2000 at 02:04:10PM -0700, Linus Torvalds wrote:
> It so happens that the vmscan stuff won't ever remove a physical page
> mapping, but that's simply because such a page CANNOT be swapped out. How
So if I write a mechanism that allows those driver-private-pages that are used
for DM
Hi,
On Tue, Oct 17, 2000 at 10:06:35PM +0200, Andrea Arcangeli wrote:
> > also don't see why any bug with kiobufs can't be fixed without the
> > expensive and complex pinning.
>
> IMHO pinning the page in the pte is less expensive and less complex than making
> rawio and the VM aware of those i
On Tue, 17 Oct 2000, Andrea Arcangeli wrote:
>
> IMHO pinning the page in the pte is less expensive and less complex than making
> rawio and the VM aware of those issues. (remap_page_range is so clean
> implementation exactly because it pins the page into the pte)
You keep on bringing up remap
On Tue, Oct 17, 2000 at 12:27:30PM -0700, David S. Miller wrote:
> Hint: smp_flush_tlb_page()
>
> Current kiobufs never need to do that, under any circumstances.
> This is not by accident.
I don't understand. flush_tlb_page() done in the context of a thread won't care
about the state of the phys
Hello,
> 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 dis
On Tue, 17 Oct 2000, Andrea Arcangeli wrote:
>
> 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?).
I'm not tal
Date:Tue, 17 Oct 2000 21:32:43 +0200
From: Andrea Arcangeli <[EMAIL PROTECTED]>
> 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 wit
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 cas
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 t
On Mon, Oct 16, 2000 at 08:11:55PM -0700, Linus Torvalds wrote:
> Oh. So to fix a bug, you say "either delete the code, or do something else
> that is completely idiotic instead"?
I'm not saying this because the "something else" doesn't look completly idiotic
to me.
> Andrea, explain to me how p
Hi,
On Mon, Oct 16, 2000 at 08:11:55PM -0700, Linus Torvalds wrote:
> I'm sure this bug will get fixed too. And the fix probably won't end up
> even being all that painful - it's probably a question of marking the page
> dirty after completing IO into it and making sure the swap-out logic does
>
Hi,
On Tue, Oct 17, 2000 at 12:13:49AM +0200, Andrea Arcangeli wrote:
>
> Correct. But the problem is that the page won't stay in physical memory after
> we finished the I/O because swap cache with page count 1 will be freed by the
> VM.
Rik has been waiting for an excuse to get deferred swapou
On Tue, 17 Oct 2000, Andrea Arcangeli wrote:
>
> If you won't delete map_user_kiobuf from your tree I think I've just provided a
> real world MM corruption case where the user send the bug report back to us if
> we only increase the reference count of the page to pin it.
Oh. So to fix a bug, y
On Mon, Oct 16, 2000 at 03:21:11PM -0700, Linus Torvalds wrote:
> Pinning will not happen.
Pinning happens every day on my box while I use rawio.
If you want to avoid pinning _userspace_ pages then we should delete
map_user_kiobuf and define a new functionality and API to replace RAWIO for
DBMS
On Mon, Oct 16, 2000 at 02:59:59PM -0700, Linus Torvalds wrote:
> No. Because "pinning" is _stupid_.
Pinning using map_user_kiobuf looks just the other way around of what we do
usually with the mmap callback of the device driver and remap_page_range. I
considered "pinning" just to convert the us
On Tue, 17 Oct 2000, Andrea Arcangeli wrote:
>
> And anyways from a design standpoint it looks much better to really pin the
> page in the pte too (just like kernel reserved pages are pinend after a
> remap_page_range).
No.
Read my emails.
"Pinning" is stupid. There are no ifs, buts, or may
On Mon, Oct 16, 2000 at 10:14:01PM +0100, Stephen C. Tweedie wrote:
> [..] If the VM
> chooses to unmap the page temporarily, then as long as the page
> remains in physical memory, then a subsequent page fault will
> reestablish the mapping. [..]
Correct. But the problem is that the page won't st
On Mon, 16 Oct 2000, Andrea Arcangeli wrote:
>
> If the page isn't locked swap_out will unmap it from the pte and anybody will
> be able to start any kind of regular VM I/O on the page.
Doesn't matter.
If you have increased the page count, the page _will_ stay in the page
cache. So everybody
On Mon, Oct 16, 2000 at 11:29:27AM -0700, Linus Torvalds wrote:
> The page count is (or should be) sufficient, and if it weren't sufficient
> that would be a bug in the swap-out handling of anonymous or shm memory. I
If the page isn't locked swap_out will unmap it from the pte and anybody will
be
Hi,
On Mon, Oct 16, 2000 at 12:08:54AM +0200, Andrea Arcangeli wrote:
> The basic problem is that map_user_kiobuf tries to map those pages calling an
> handle_mm_fault on their virtual addresses and it's thinking that when
> handle_mm_fault returns 1 the page is mapped. That's wrong.
Good poin
On Mon, 16 Oct 2000, Andrea Arcangeli wrote:
>
> I'm also not convinced that only increasing the page count in the critical
> section in map_user_kiobuf is enough because swap_out doesn't care about the
> page count (in 2.2.x rawio it's taking the page lock). The page count is
> significant as
Hi,
On Fri, Oct 13, 2000 at 12:30:49PM +0100, Malcolm Beattie wrote:
> free_kiovec(1, &iobuf);/* does an implicit unlock_kiovec */
>
> It doesn't do an unmap_kiobuf(iobuf) so I don't understand where
> the per-page map->count that map_user_kiobuf incremented gets
> decremented again. An
Linus Torvalds wrote:
>> In article <[EMAIL PROTECTED]>,
>> <[EMAIL PROTECTED]> wrote:
>> >
>> >I have a user buffer and i want to map it to kernel address space
>> >can anyone tell how to do this like in AIX we have xmattach
>
>> Note that it is usually MUCH better to do this the other way aroun
On Sat, Oct 14, 2000 at 07:17:57PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 14 Oct 2000, Rogier Wolff wrote:
> > > Note that it is usually MUCH better to do this the other way around:
> > > having a kernel-side buffer, and mapping that into user space. I don't
> > > understand why so many peop
Linus Torvalds wrote:
>
>
> On Sat, 14 Oct 2000, Rogier Wolff wrote:
> > > Note that it is usually MUCH better to do this the other way around:
> > > having a kernel-side buffer, and mapping that into user space. I don't
> > > understand why so many people always want to do it the wrong way arou
On Sat, 14 Oct 2000, Rogier Wolff wrote:
> > Note that it is usually MUCH better to do this the other way around:
> > having a kernel-side buffer, and mapping that into user space. I don't
> > understand why so many people always want to do it the wrong way around..
>
> Provided this wasn't a r
Hello,
> Note that it is usually MUCH better to do this the other way around:
> having a kernel-side buffer, and mapping that into user space. I don't
> understand why so many people always want to do it the wrong way around..
Well, I totally agree. Unfortunately, my fellow driver developers
se
Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED]> wrote:
> >
> >I have a user buffer and i want to map it to kernel address space
> >can anyone tell how to do this like in AIX we have xmattach
>
> Note that it is usually MUCH better to do this the other way around:
>
In article <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>
>I have a user buffer and i want to map it to kernel address space
>can anyone tell how to do this like in AIX we have xmattach
Note that it is usually MUCH better to do this the other way around:
having a kernel-side buffer, and mappi
Hello,
> On 13 Oct 00 at 15:31, [EMAIL PROTECTED] wrote:
>
> > I have a user buffer and i want to map it to kernel address space
> > can anyone tell how to do this like in AIX we have xmattach
>
> Look at mm/memory.c:map_user_kiobuf. It is used by drivers/char/raw.c,
> or by drivers/media/video
[EMAIL PROTECTED] writes:
> I have a user buffer and i want to map it to kernel address space
> can anyone tell how to do this like in AIX we have xmattach
In 2.2, you're better off providing a fake character device driver
which allocates the memory in kernel space and lets the user mmap it.
In 2
On 13 Oct 00 at 15:31, [EMAIL PROTECTED] wrote:
> I have a user buffer and i want to map it to kernel address space
> can anyone tell how to do this like in AIX we have xmattach
Look at mm/memory.c:map_user_kiobuf. It is used by drivers/char/raw.c,
or by drivers/media/video/bttv-driver.c, for ex
65 matches
Mail list logo
