Re: COW in userspace

[Jerome Glisse <j.glisse@gmail.com>]

On Fri, Aug 20, 2021 at 03:13:11PM +0200, Ralf Ramsauer wrote:
> Dear mm folks,
> 
> I have an issue, where it would be great to have a COW-backed virtual
> memory area within an userspace process. I know there's the possibility
> to have a file-backed MAP_SHARED vma, which is later duplicated with
> MAP_PRIVATE, but that's not exactly what I'm looking for.
> 
> Say I have an anonymous page-aligned VMA a, with MAP_PRIVATE and
> PROT_RW. Userspace happily writes to/reads from it. At some point in
> time, I want to 'snapshot' that single VMA within the context of the
> process and without the need to fork(). Say there's something like
> 
>   a = mmap(0, len, PROT_RW, MAP_ANON | MAP_POPULATE, -1, 0);
>   [... fill a ...]
> 
>   b = mmdup(a, len, PROT_READ);
> 
> b shall be the new base pointer of a new VMA that is backed by COW
> mechanisms. After mmdup, those regular COW mechanisms do the rest: both
> VMAs (a and b) will fault on subsequent writes and duplicate the
> previously shared physical mapping, pretty much what cow_fault or
> shared_fault does.
> 
> Afaict, this, or at least something like this is currently not supported
> by the kernel. Is that correct? If so, why? Generally spoken, is it a
> bad idea?

Not supported. I guess they never was an enticing use case, ie a known
application which we care about which would benefit from such feature.
Proving that means you have to do the kernel patch and update the app
to get some benchmark.

I also think that this would be too much like MAP_COPY which is a bad
idea for file back vma (see [1]). So even if we were to restrict it to
anonymous memory it might make people feel uneasy as one could fear that
some crazy folks would try to extend it to file back vma.

Note that what is in [1] does not apply to anonymous memory as anonymous
memory with anon_vma already have per page versioning tracking (ignoring
the can of worm that COW is and all the issues we are finding about it).


[1] https://yarchive.net/comp/linux/map_copy.html


> 
> I digged a bit into the mm code, and I think all the stuff that would be
> required is already there, so I wonder what I'm missing.
> 
> 
> This is some related work I found on that topic:
> 
> https://sfb876.tu-dortmund.de/PublicPublicationFiles/kotthaus_2016a.pdf
> 
> They implement mmapcopy(), which pretty much would fulfill my
> requirements. However, I still wonder why the kernel doesn't support
> something like that by default, so maybe some mm expert could shed light
> on this.
> 

Quickly looking at results it is not impressive, it only improve the
situation if you compare it to KSM. Original code seems to be within
the margin error from performance point of view.

Cheers,
Jérôme Glisse