> +ssize_t remap_pages(struct mm_struct *dst_mm, struct mm_struct *src_mm,
> + unsigned long dst_start, unsigned long src_start,
> + unsigned long len, __u64 mode)
> +{
> + struct vm_area_struct *src_vma, *dst_vma;
> + long err = -EINVAL;
> + pmd_t *src_p
On Thu, Mar 5, 2015 at 10:51 AM, Andrea Arcangeli wrote:
>
> Thanks for your idea that the UFFDIO_COPY is faster, the userland code
> we submitted for qemu only uses UFFDIO_COPY|ZEROPAGE, it never uses
> UFFDIO_REMAP.
Ok. So there's no actual expected use of the remap interface. Good.
That makes
On Thu, Mar 05, 2015 at 09:39:48AM -0800, Linus Torvalds wrote:
> Is this really worth it? On real loads? That people are expected to use?
I fully agree that it's not worth merging upstream UFFDIO_REMAP until
(and if) a real world usage for it will showup. To further clarify:
would this not have b
On Thu, Mar 5, 2015 at 9:18 AM, Andrea Arcangeli wrote:
> remap_pages is the lowlevel mm helper needed to implement
> UFFDIO_REMAP.
This function is nasty nasty nasty.
Is this really worth it? On real loads? That people are expected to use?
Considering how we just got rid of one special magic V
remap_pages is the lowlevel mm helper needed to implement
UFFDIO_REMAP.
Signed-off-by: Andrea Arcangeli
---
include/linux/userfaultfd_k.h | 17 ++
mm/huge_memory.c | 120 ++
mm/userfaultfd.c | 526 ++
3 files changed, 663
