On Tue, Oct 24, 2023 at 7:27 AM David Hildenbrand wrote:
>
> On 23.10.23 20:56, Suren Baghdasaryan wrote:
> > On Mon, Oct 23, 2023 at 5:29 AM David Hildenbrand wrote:
> >>
> >> Focusing on validate_remap_areas():
> >>
> >>> +
> >>> +static int validate_remap_areas(struct vm_area_struct *src_vma,
On 23.10.23 20:56, Suren Baghdasaryan wrote:
On Mon, Oct 23, 2023 at 5:29 AM David Hildenbrand wrote:
Focusing on validate_remap_areas():
+
+static int validate_remap_areas(struct vm_area_struct *src_vma,
+ struct vm_area_struct *dst_vma)
+{
+ /* Only allow
On Mon, Oct 23, 2023 at 11:37 AM Peter Xu wrote:
>
> On Mon, Oct 23, 2023 at 10:43:49AM -0700, Suren Baghdasaryan wrote:
> > > Maybe we should follow what it does with mremap()? Then your current code
> > > is fine. Maybe that's the better start.
> >
> > I think that was the original intention,
On Mon, Oct 23, 2023 at 8:53 AM David Hildenbrand wrote:
>
> On 23.10.23 14:29, David Hildenbrand wrote:
> >> +
> >> +/* Only allow remapping if both are mlocked or both aren't */
> >> +if ((src_vma->vm_flags & VM_LOCKED) != (dst_vma->vm_flags &
> >> VM_LOCKED))
> >> +return
On Mon, Oct 23, 2023 at 5:29 AM David Hildenbrand wrote:
>
> Focusing on validate_remap_areas():
>
> > +
> > +static int validate_remap_areas(struct vm_area_struct *src_vma,
> > + struct vm_area_struct *dst_vma)
> > +{
> > + /* Only allow remapping if both have the
On Mon, Oct 23, 2023 at 10:43:49AM -0700, Suren Baghdasaryan wrote:
> > Maybe we should follow what it does with mremap()? Then your current code
> > is fine. Maybe that's the better start.
>
> I think that was the original intention, basically treating remapping
> as a write operation. Maybe I
On Sun, Oct 22, 2023 at 10:02 AM Peter Xu wrote:
>
> On Thu, Oct 19, 2023 at 02:24:06PM -0700, Suren Baghdasaryan wrote:
> > On Thu, Oct 12, 2023 at 3:00 PM Peter Xu wrote:
> > >
> > > On Sun, Oct 08, 2023 at 11:42:27PM -0700, Suren Baghdasaryan wrote:
> > > > From: Andrea Arcangeli
> > > >
> >
On Mon, Oct 23, 2023 at 9:36 AM David Hildenbrand wrote:
>
> On 23.10.23 14:03, David Hildenbrand wrote:
> > On 22.10.23 17:46, Peter Xu wrote:
> >> On Fri, Oct 20, 2023 at 07:16:19PM +0200, David Hildenbrand wrote:
> >>> These are rather the vibes I'm getting from Peter. "Why rename it, could
>
On 23.10.23 14:03, David Hildenbrand wrote:
On 22.10.23 17:46, Peter Xu wrote:
On Fri, Oct 20, 2023 at 07:16:19PM +0200, David Hildenbrand wrote:
These are rather the vibes I'm getting from Peter. "Why rename it, could
confuse people because the original patches are old", "Why exclude it if it
On 23.10.23 14:29, David Hildenbrand wrote:
+
+ /* Only allow remapping if both are mlocked or both aren't */
+ if ((src_vma->vm_flags & VM_LOCKED) != (dst_vma->vm_flags & VM_LOCKED))
+ return -EINVAL;
+
+ if (!(src_vma->vm_flags & VM_WRITE) || !(dst_vma->vm_flags
Focusing on validate_remap_areas():
+
+static int validate_remap_areas(struct vm_area_struct *src_vma,
+ struct vm_area_struct *dst_vma)
+{
+ /* Only allow remapping if both have the same access and protection */
+ if ((src_vma->vm_flags &
On 22.10.23 17:46, Peter Xu wrote:
On Fri, Oct 20, 2023 at 07:16:19PM +0200, David Hildenbrand wrote:
These are rather the vibes I'm getting from Peter. "Why rename it, could
confuse people because the original patches are old", "Why exclude it if it
has been included in the original patches".
On Thu, Oct 19, 2023 at 02:24:06PM -0700, Suren Baghdasaryan wrote:
> On Thu, Oct 12, 2023 at 3:00 PM Peter Xu wrote:
> >
> > On Sun, Oct 08, 2023 at 11:42:27PM -0700, Suren Baghdasaryan wrote:
> > > From: Andrea Arcangeli
> > >
> > > Implement the uABI of UFFDIO_MOVE ioctl.
> > > UFFDIO_COPY
On Fri, Oct 20, 2023 at 07:16:19PM +0200, David Hildenbrand wrote:
> These are rather the vibes I'm getting from Peter. "Why rename it, could
> confuse people because the original patches are old", "Why exclude it if it
> has been included in the original patches". Not the kind of reasoning I can
The sub-feature in question (cross-mm) has no solid use cases; at this
point I am not even convinced the use case you raised requires
*userfaultfd*; for the purpose of moving a whole VMA worth of pages
between two processes; I don't see the immediate need to get userfaultfd
involved and move
On Fri, Oct 20, 2023 at 3:02 AM David Hildenbrand wrote:
>
> On 19.10.23 21:53, Peter Xu wrote:
> > On Thu, Oct 19, 2023 at 05:41:01PM +0200, David Hildenbrand wrote:
> >> That's not my main point. It can easily become a maintenance burden without
> >> any real use cases yet that we are willing
On 19.10.23 21:53, Peter Xu wrote:
On Thu, Oct 19, 2023 at 05:41:01PM +0200, David Hildenbrand wrote:
That's not my main point. It can easily become a maintenance burden without
any real use cases yet that we are willing to support.
That's why I requested a few times that we can discuss the
ts/Suren-Baghdasaryan/mm-rmap-support-move-to-different-root-anon_vma-in-folio_move_anon_rmap/20231009-144552
> base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
> mm-everything
> patch link:
> https://lore.kernel.org/r/20231009064230.2952396-3-surenb%40google.com
> pa
On Fri, Oct 13, 2023 at 9:08 AM Peter Xu wrote:
>
> On Fri, Oct 13, 2023 at 11:56:31AM +0200, David Hildenbrand wrote:
> > Hi Peter,
>
> Hi, David,
>
> >
> > > I used to have the same thought with David on whether we can simplify the
> > > design to e.g. limit it to single mm. Then I found that
On Thu, Oct 12, 2023 at 3:00 PM Peter Xu wrote:
>
> On Sun, Oct 08, 2023 at 11:42:27PM -0700, Suren Baghdasaryan wrote:
> > From: Andrea Arcangeli
> >
> > Implement the uABI of UFFDIO_MOVE ioctl.
> > UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
> > needs pages to be
On Thu, Oct 19, 2023 at 01:02:39PM -0700, Suren Baghdasaryan wrote:
> Hi Folks,
> Sorry, I'm just catching up on all the comments in this thread after a
Not a problem.
> week-long absence. Will be addressing other questions separately but
> for cross-mm one, I think the best way forward would be
On Thu, Oct 19, 2023 at 12:53 PM Peter Xu wrote:
>
> On Thu, Oct 19, 2023 at 05:41:01PM +0200, David Hildenbrand wrote:
> > That's not my main point. It can easily become a maintenance burden without
> > any real use cases yet that we are willing to support.
>
> That's why I requested a few times
On Thu, Oct 19, 2023 at 05:41:01PM +0200, David Hildenbrand wrote:
> That's not my main point. It can easily become a maintenance burden without
> any real use cases yet that we are willing to support.
That's why I requested a few times that we can discuss the complexity of
cross-mm support
On 17.10.23 20:59, Peter Xu wrote:
David,
On Tue, Oct 17, 2023 at 05:55:10PM +0200, David Hildenbrand wrote:
Don't get me wrong, but this feature is already complicated enough that we
should really think twice if we want to make this even more complicated and
harder to maintain -- because once
://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
mm-everything
patch link:
https://lore.kernel.org/r/20231009064230.2952396-3-surenb%40google.com
patch subject: [PATCH v3 2/3] userfaultfd: UFFDIO_MOVE uABI
config: i386-randconfig-141-20231017
(https://download.01.org/0day-ci/archive/20231018
David,
On Tue, Oct 17, 2023 at 05:55:10PM +0200, David Hildenbrand wrote:
> Don't get me wrong, but this feature is already complicated enough that we
> should really think twice if we want to make this even more complicated and
> harder to maintain -- because once it's in we all know it's hard
On 16.10.23 21:01, Peter Xu wrote:
David,
Hi Peter,
Basically I see it a potential way of moving memory efficiently especially
with thp.
It's an interesting use case indeed. The questions would be if this is (a) a
use case we want to support; (b) why we need to make that decision now and
David,
On Mon, Oct 16, 2023 at 08:01:10PM +0200, David Hildenbrand wrote:
> [...]
>
> > > > Actually, even though I have no solid clue, but I had a feeling that
> > > > there
> > > > can be some interesting way to leverage this across-mm movement, while
> > > > keeping things all safe (by e.g.
[...]
Actually, even though I have no solid clue, but I had a feeling that there
can be some interesting way to leverage this across-mm movement, while
keeping things all safe (by e.g. elaborately requiring other proc to create
uffd and deliver to this proc).
Okay, but no real use cases yet.
On Fri, Oct 13, 2023 at 09:49:10AM -0700, Lokesh Gidra wrote:
> On Fri, Oct 13, 2023 at 9:08 AM Peter Xu wrote:
> >
> > On Fri, Oct 13, 2023 at 11:56:31AM +0200, David Hildenbrand wrote:
> > > Hi Peter,
> >
> > Hi, David,
> >
> > >
> > > > I used to have the same thought with David on whether we
On Fri, Oct 13, 2023 at 9:08 AM Peter Xu wrote:
>
> On Fri, Oct 13, 2023 at 11:56:31AM +0200, David Hildenbrand wrote:
> > Hi Peter,
>
> Hi, David,
>
> >
> > > I used to have the same thought with David on whether we can simplify the
> > > design to e.g. limit it to single mm. Then I found that
On Fri, Oct 13, 2023 at 11:56:31AM +0200, David Hildenbrand wrote:
> Hi Peter,
Hi, David,
>
> > I used to have the same thought with David on whether we can simplify the
> > design to e.g. limit it to single mm. Then I found that the trickiest is
> > actually patch 1 together with the anon_vma
On 12.10.23 22:11, Peter Xu wrote:
On Mon, Oct 09, 2023 at 05:29:08PM +0100, Lokesh Gidra wrote:
On Mon, Oct 9, 2023 at 5:24 PM David Hildenbrand wrote:
On 09.10.23 18:21, Suren Baghdasaryan wrote:
On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote:
On 09.10.23 08:42, Suren
On Sun, Oct 08, 2023 at 11:42:27PM -0700, Suren Baghdasaryan wrote:
> From: Andrea Arcangeli
>
> Implement the uABI of UFFDIO_MOVE ioctl.
> UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
> needs pages to be allocated [1]. However, with UFFDIO_MOVE, if pages are
>
On Mon, Oct 09, 2023 at 05:29:08PM +0100, Lokesh Gidra wrote:
> On Mon, Oct 9, 2023 at 5:24 PM David Hildenbrand wrote:
> >
> > On 09.10.23 18:21, Suren Baghdasaryan wrote:
> > > On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote:
> > >>
> > >> On 09.10.23 08:42, Suren Baghdasaryan wrote:
>
On Mon, Oct 9, 2023 at 5:57 PM Lokesh Gidra wrote:
>
> On Mon, Oct 9, 2023 at 9:29 AM Lokesh Gidra wrote:
> >
> > On Mon, Oct 9, 2023 at 5:24 PM David Hildenbrand wrote:
> > >
> > > On 09.10.23 18:21, Suren Baghdasaryan wrote:
> > > > On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand
> > > >
On Mon, Oct 9, 2023 at 9:29 AM Lokesh Gidra wrote:
>
> On Mon, Oct 9, 2023 at 5:24 PM David Hildenbrand wrote:
> >
> > On 09.10.23 18:21, Suren Baghdasaryan wrote:
> > > On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote:
> > >>
> > >> On 09.10.23 08:42, Suren Baghdasaryan wrote:
> > >>>
On Mon, Oct 9, 2023 at 5:24 PM David Hildenbrand wrote:
>
> On 09.10.23 18:21, Suren Baghdasaryan wrote:
> > On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote:
> >>
> >> On 09.10.23 08:42, Suren Baghdasaryan wrote:
> >>> From: Andrea Arcangeli
> >>>
> >>> Implement the uABI of UFFDIO_MOVE
On 09.10.23 18:21, Suren Baghdasaryan wrote:
On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote:
On 09.10.23 08:42, Suren Baghdasaryan wrote:
From: Andrea Arcangeli
Implement the uABI of UFFDIO_MOVE ioctl.
UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
needs
On Mon, Oct 9, 2023 at 7:38 AM David Hildenbrand wrote:
>
> On 09.10.23 08:42, Suren Baghdasaryan wrote:
> > From: Andrea Arcangeli
> >
> > Implement the uABI of UFFDIO_MOVE ioctl.
> > UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
> > needs pages to be allocated [1].
On 09.10.23 08:42, Suren Baghdasaryan wrote:
From: Andrea Arcangeli
Implement the uABI of UFFDIO_MOVE ioctl.
UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
needs pages to be allocated [1]. However, with UFFDIO_MOVE, if pages are
available (in userspace) for recycling,
From: Andrea Arcangeli
Implement the uABI of UFFDIO_MOVE ioctl.
UFFDIO_COPY performs ~20% better than UFFDIO_MOVE when the application
needs pages to be allocated [1]. However, with UFFDIO_MOVE, if pages are
available (in userspace) for recycling, as is usually the case in heap
compaction
42 matches
Mail list logo
