Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Dr. David Alan Gilbert
* Linus Torvalds (torva...@linux-foundation.org) wrote: > On Mon, Oct 6, 2014 at 12:41 PM, Andrea Arcangeli wrote: > > > > Of course if somebody has better ideas on how to resolve an anonymous > > userfault they're welcome. > > So I'd *much* rather have a "write()" style interface (ie _copying_ >

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Dr. David Alan Gilbert
* Paolo Bonzini (pbonz...@redhat.com) wrote: > Il 07/10/2014 19:07, Dr. David Alan Gilbert ha scritto: > >> > > >> > So I'd *much* rather have a "write()" style interface (ie _copying_ > >> > bytes from user space into a newly allocated page that gets mapped) > >> > than a "remap page" style inter

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Paolo Bonzini
Il 07/10/2014 19:07, Dr. David Alan Gilbert ha scritto: >> > >> > So I'd *much* rather have a "write()" style interface (ie _copying_ >> > bytes from user space into a newly allocated page that gets mapped) >> > than a "remap page" style interface > Something like that might work for the postcopy

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Linus Torvalds
On Tue, Oct 7, 2014 at 10:19 AM, Andrea Arcangeli wrote: > > I see what you mean. The only cons I see is that we couldn't use then > recv(tmp_addr, PAGE_SIZE), remap_anon_pages(faultaddr, tmp_addr, > PAGE_SIZE, ..) and retain the zerocopy behavior. Or how could we? > There's no recvfile(userfault

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Peter Feiner
On Tue, Oct 07, 2014 at 05:52:47PM +0200, Andrea Arcangeli wrote: > I probably grossly overestimated the benefits of resolving the > userfault with a zerocopy page move, sorry. [...] For posterity, I think it's worth noting that most expensive aspect of a TLB shootdown is the interprocessor interr

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Andy Lutomirski
On Tue, Oct 7, 2014 at 8:52 AM, Andrea Arcangeli wrote: > On Tue, Oct 07, 2014 at 04:19:13PM +0200, Andrea Arcangeli wrote: >> mremap like interface, or file+commands protocol interface. I tend to >> like mremap more, that's why I opted for a remap_anon_pages syscall >> kept orthogonal to the user

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Andrea Arcangeli
On Tue, Oct 07, 2014 at 04:19:13PM +0200, Andrea Arcangeli wrote: > mremap like interface, or file+commands protocol interface. I tend to > like mremap more, that's why I opted for a remap_anon_pages syscall > kept orthogonal to the userfaultfd functionality (remap_anon_pages > could be also used s

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Andrea Arcangeli
Hello, On Tue, Oct 07, 2014 at 08:47:59AM -0400, Linus Torvalds wrote: > On Mon, Oct 6, 2014 at 12:41 PM, Andrea Arcangeli wrote: > > > > Of course if somebody has better ideas on how to resolve an anonymous > > userfault they're welcome. > > So I'd *much* rather have a "write()" style interface

Re: [Qemu-devel] [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Andrea Arcangeli
Hi Kirill, On Tue, Oct 07, 2014 at 02:10:26PM +0300, Kirill A. Shutemov wrote: > On Fri, Oct 03, 2014 at 07:08:00PM +0200, Andrea Arcangeli wrote: > > There's one constraint enforced to allow this simplification: the > > source pages passed to remap_anon_pages must be mapped only in one > > vma, b

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Linus Torvalds
On Mon, Oct 6, 2014 at 12:41 PM, Andrea Arcangeli wrote: > > Of course if somebody has better ideas on how to resolve an anonymous > userfault they're welcome. So I'd *much* rather have a "write()" style interface (ie _copying_ bytes from user space into a newly allocated page that gets mapped) t

Re: [Qemu-devel] [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-07 Thread Kirill A. Shutemov
On Fri, Oct 03, 2014 at 07:08:00PM +0200, Andrea Arcangeli wrote: > There's one constraint enforced to allow this simplification: the > source pages passed to remap_anon_pages must be mapped only in one > vma, but this is not a limitation when used to handle userland page > faults with MADV_USERFAU

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-06 Thread Andrea Arcangeli
Hello, On Mon, Oct 06, 2014 at 09:55:41AM +0100, Dr. David Alan Gilbert wrote: > * Linus Torvalds (torva...@linux-foundation.org) wrote: > > On Fri, Oct 3, 2014 at 10:08 AM, Andrea Arcangeli > > wrote: > > > > > > Overall this looks a fairly small change to the rmap code, notably > > > less intr

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-06 Thread Dr. David Alan Gilbert
* Linus Torvalds (torva...@linux-foundation.org) wrote: > On Fri, Oct 3, 2014 at 10:08 AM, Andrea Arcangeli wrote: > > > > Overall this looks a fairly small change to the rmap code, notably > > less intrusive than the nonlinear vmas created by remap_file_pages. > > Considering that remap_file_pag

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-03 Thread Linus Torvalds
On Fri, Oct 3, 2014 at 10:08 AM, Andrea Arcangeli wrote: > > Overall this looks a fairly small change to the rmap code, notably > less intrusive than the nonlinear vmas created by remap_file_pages. Considering that remap_file_pages() was an unmitigated disaster, and -mm has a patch to remove it e

[PATCH 10/17] mm: rmap preparation for remap_anon_pages

2014-10-03 Thread Andrea Arcangeli
remap_anon_pages (unlike remap_file_pages) tries to be non intrusive in the rmap code. As far as the rmap code is concerned, rmap_anon_pages only alters the page->mapping and page->index. It does it while holding the page lock. However there are a few places that in presence of anon pages are allo