From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5451C4338F for ; Fri, 20 Aug 2021 23:12:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 53C6E6117A for ; Fri, 20 Aug 2021 23:12:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 53C6E6117A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CC0E68D0001; Fri, 20 Aug 2021 19:12:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C70C66B0072; Fri, 20 Aug 2021 19:12:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B38668D0001; Fri, 20 Aug 2021 19:12:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0215.hostedemail.com [216.40.44.215]) by kanga.kvack.org (Postfix) with ESMTP id 969BD6B0071 for ; Fri, 20 Aug 2021 19:12:44 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3CFD3184C6E70 for ; Fri, 20 Aug 2021 23:12:44 +0000 (UTC) X-FDA: 78497010648.39.262AE59 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf19.hostedemail.com (Postfix) with ESMTP id E5B4EB00009D for ; Fri, 20 Aug 2021 23:12:43 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id f3so6838234plg.3 for ; Fri, 20 Aug 2021 16:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=jMfUekJvIkYaVB92d/NqWk9dJN7PCF4pZjW6NNDYljU=; b=elhhp5839pl5eedW5aOF6p8D0E3NcJNI8ufr+Bi84+wFJNo1ys6jJRr2luy6GXputl 7gEfLJkJLlmB89OJgOM2XpvXxl1dNlr2T9uxmHau9r5DZW46bIGgj8i/KMHuZY6fVyp9 Lh7/ZmVVh2pRl+IEvkIdwbmUhHGVfd9zVIlOSKKA9ChdKKVQP2ffaUhVSUcYAzw1GK2n dc7+RgD7a/nfVRMXWUsLlobelw3S+Nm8plu9ELhevnArVRHx3iKY1TfKlhUzOm0Ww6KM pRAmX84y95Zg6LF+U+ZYHTGwPV6gG8CMzW90vvHLeN6CaPL6GHHAxlS7wEWd0kNoVGra bLCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=jMfUekJvIkYaVB92d/NqWk9dJN7PCF4pZjW6NNDYljU=; b=AvOO8P/OuvDjnGOkahvyjDrSe37KdEZP6mx4UqoCP6GuKEsLKtUgj+eJ6YlnVINige PBddFjTKl80x7vId3BRiZZ03KB136qO00SxcAyXgcscQpHR6mpSKPfbXi4FDKG7IGRro C5DgT2RjCv7Q8ulQBaAUDVfNyV4wd82bUT5z8TnzqxMYMSRsW1XgAdFhOr69Pp8MJvZL r79YIrD8gixCj59uBnVaqyAD4cvzburzXy/PL7doEAV1nz2w0Gymw7skrk6VWzDXt+j5 ECXWwom492Ijul2l6rTi9Suz4XxqEWFYvV0XsdE8AdmiLlWnKb4vPx0BY7WmjDxWItUe DZZQ== X-Gm-Message-State: AOAM5303+qT5OfGUliO43OnpOnbWnwvexfjZhp+mhJrHhwM/6LSDaOtK QtXRNCAPHY4wx4SvbuWQBHoeWXphfNIkSg== X-Google-Smtp-Source: ABdhPJwpw020sCD6pb4rgTkdTMu3op6/TsSsOX1HlSqHZdMALwIOjSu1mMqrOufYgoe7DVwvDivcYQ== X-Received: by 2002:a17:90a:9289:: with SMTP id n9mr6819130pjo.27.1629501162955; Fri, 20 Aug 2021 16:12:42 -0700 (PDT) Received: from gmail.com ([2601:647:6400:270::c6c]) by smtp.gmail.com with ESMTPSA id x14sm8113358pfa.127.2021.08.20.16.12.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Aug 2021 16:12:42 -0700 (PDT) Date: Fri, 20 Aug 2021 16:12:29 -0700 From: Jerome Glisse To: Ralf Ramsauer Cc: linux-mm@kvack.org, Wolfgang Mauerer , Mario Mintel Subject: Re: COW in userspace Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E5B4EB00009D Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=elhhp583; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of jglisse@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=jglisse@gmail.com X-Rspamd-Server: rspam01 X-Stat-Signature: ghd6irnbnyf6r8b65191nsahq56fbez9 X-HE-Tag: 1629501163-582811 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 20, 2021 at 03:13:11PM +0200, Ralf Ramsauer wrote: > Dear mm folks, >=20 > 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. >=20 > 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 >=20 > a =3D mmap(0, len, PROT_RW, MAP_ANON | MAP_POPULATE, -1, 0); > [... fill a ...] >=20 > b =3D mmdup(a, len, PROT_READ); >=20 > 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. >=20 > Afaict, this, or at least something like this is currently not supporte= d > 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 >=20 > I digged a bit into the mm code, and I think all the stuff that would b= e > required is already there, so I wonder what I'm missing. >=20 >=20 > This is some related work I found on that topic: >=20 > https://sfb876.tu-dortmund.de/PublicPublicationFiles/kotthaus_2016a.pdf >=20 > 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 ligh= t > on this. >=20 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=E9r=F4me Glisse