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=-19.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=ham 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 CA0EBC433DB for ; Sun, 14 Mar 2021 04:19:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 29CB464D9C for ; Sun, 14 Mar 2021 04:19:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 29CB464D9C Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ACCB76B0070; Sat, 13 Mar 2021 23:19:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A57726B0071; Sat, 13 Mar 2021 23:19:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A9416B0072; Sat, 13 Mar 2021 23:19:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0191.hostedemail.com [216.40.44.191]) by kanga.kvack.org (Postfix) with ESMTP id 67EEE6B0070 for ; Sat, 13 Mar 2021 23:19:56 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 18B9118022BCC for ; Sun, 14 Mar 2021 04:19:56 +0000 (UTC) X-FDA: 77917176792.10.7953E28 Received: from mail-oo1-f53.google.com (mail-oo1-f53.google.com [209.85.161.53]) by imf06.hostedemail.com (Postfix) with ESMTP id 9B3C2C0001F7 for ; Sun, 14 Mar 2021 04:19:55 +0000 (UTC) Received: by mail-oo1-f53.google.com with SMTP id n6-20020a4ac7060000b02901b50acc169fso2546560ooq.12 for ; Sat, 13 Mar 2021 20:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=kixZrJkwNjUoR8zMK2p//jPoJv3zOuB8QGV2eNGzAyA=; b=v8QVnTHZHCVWu9EH2kSatOoL53oTW7ZGKHoZ66e5Ivw5EVDSh/cz1sn2AhTU/gUDhW RLNjWTnAGGDqNT+aIpfk/crGQH+y69nX1r5+EyH2fMWNvsTSrhIj52eP/3EfwxA9lGB0 6zL9lGl6a/qCEQ2Gey41NP4+ugxL8UXWFHhVX2v2TmnXcWSD9Znhd0Q8cp3CjjWmoWla 0kBv5dcqXlhGR9tgfg7d+u86Crv2T2c+xXV90ieVsMHJY44jtHXs5UaRCOQueJYYmqao nGgm1Bd83/ZasItTp62QhhY++J/Mx5AeNaQUa26Kms5rOSIg1jblEfgu/n9dUP7fG3dJ OIsA== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=kixZrJkwNjUoR8zMK2p//jPoJv3zOuB8QGV2eNGzAyA=; b=OhFT2TJ/Hbzgwr+MwhbsffY27g0xVhC/vz9URHQ+xJkZYwTZD386HjnTBUhKliNrH7 L5/HP5TDuO8eogB/jp9e3amNiziRcEduERRgHSBJSAfQGX+NdB8wiMeITXtjY65Gu4LP VEnvkXSrj40g3AqR5eS7EesiVSanQH8ug2eP8E7a7Xv6Bv3ubC1Ps3CDUxBB1gOrtGVX 3ot530DS5sGJWcHDcxGWven+0kQ09h+9uMV/EMyXM4iifX5OL6qUwX58jQCdqcG6gVa8 fB5AGZK95YDfixMjLA+T1mijB82JCYwT/q6vvztmU7F/u2yVV6GT+R2FCVaV7+GjOeyp 8Uwg== X-Gm-Message-State: AOAM531gXLOaX/T1khrA/9xG0UOeSTNMBrPeTgQS2ylvdYrpOCxyDaK3 OyyKk7IwsSQdXWP6QhJojB0Z9w== X-Google-Smtp-Source: ABdhPJwcGvDEC+R1bqzuQPSx98+QkM3mYsVg4BQUjFxh2JMgLz9PzOsjvi0InQqiac1WKpfn+f8ybA== X-Received: by 2002:a4a:45d5:: with SMTP id y204mr8994074ooa.33.1615695594687; Sat, 13 Mar 2021 20:19:54 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id n22sm4284425oie.32.2021.03.13.20.19.52 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Sat, 13 Mar 2021 20:19:54 -0800 (PST) Date: Sat, 13 Mar 2021 20:19:38 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Brian Geffon cc: Andrew Morton , Axel Rasmussen , Lokesh Gidra , Mike Rapoport , Peter Xu , Hugh Dickins , "Michael S . Tsirkin" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andy Lutomirski , Vlastimil Babka , Andrea Arcangeli , Sonny Rao , Minchan Kim , "Kirill A . Shutemov" , Dmitry Safonov , Michael Kerrisk , Alejandro Colomar Subject: Re: [PATCH] mm: Allow shmem mappings with MREMAP_DONTUNMAP In-Reply-To: <20210303175235.3308220-1-bgeffon@google.com> Message-ID: References: <20210303175235.3308220-1-bgeffon@google.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 9B3C2C0001F7 X-Stat-Signature: cnnoc4e1uyxx8p6o4duck48fiu7a4e8u Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=mail-oo1-f53.google.com; client-ip=209.85.161.53 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615695595-221651 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 Wed, 3 Mar 2021, Brian Geffon wrote: > Currently MREMAP_DONTUNMAP only accepts private anonymous mappings. This change > will widen the support to include shmem mappings. The primary use case > is to support MREMAP_DONTUNMAP on mappings which may have been created from > a memfd. > > Lokesh Gidra who works on the Android JVM, provided an explanation of how such > a feature will improve Android JVM garbage collection: > "Android is developing a new garbage collector (GC), based on userfaultfd. The > garbage collector will use userfaultfd (uffd) on the java heap during compaction. > On accessing any uncompacted page, the application threads will find it missing, > at which point the thread will create the compacted page and then use UFFDIO_COPY > ioctl to get it mapped and then resume execution. Before starting this compaction, > in a stop-the-world pause the heap will be mremap(MREMAP_DONTUNMAP) so that the > java heap is ready to receive UFFD_EVENT_PAGEFAULT events after resuming execution. > > To speedup mremap operations, pagetable movement was optimized by moving PUD entries > instead of PTE entries [1]. It was necessary as mremap of even modest sized memory > ranges also took several milliseconds, and stopping the application for that long > isn't acceptable in response-time sensitive cases. With UFFDIO_CONTINUE feature [2], > it will be even more efficient to implement this GC, particularly the 'non-moveable' > portions of the heap. It will also help in reducing the need to copy (UFFDIO_COPY) > the pages. However, for this to work, the java heap has to be on a 'shared' vma. > Currently MREMAP_DONTUNMAP only supports private anonymous mappings, this patch will > enable using UFFDIO_CONTINUE for the new userfaultfd-based heap compaction." > > [1] https://lore.kernel.org/linux-mm/20201215030730.NC3CU98e4%25akpm@linux-foundation.org/ > [2] https://lore.kernel.org/linux-mm/20210302000133.272579-1-axelrasmussen@google.com/ > --- > mm/mremap.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/mremap.c b/mm/mremap.c > index ec8f840399ed..6934d199da54 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -653,8 +653,7 @@ static struct vm_area_struct *vma_to_resize(unsigned long addr, > return ERR_PTR(-EINVAL); > } > > - if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) || > - vma->vm_flags & VM_SHARED)) > + if (flags & MREMAP_DONTUNMAP && !(vma_is_anonymous(vma) || vma_is_shmem(vma))) > return ERR_PTR(-EINVAL); > > if (is_vm_hugetlb_page(vma)) > -- Yet something to improve... Thanks for extending MREMAP_DONTUNMAP to shmem, but I think this patch goes in the wrong direction, complicating when it should be generalizing: the mremap syscall is about rearranging the user's virtual address space, and is not specific to the underlying anonymous or shmem or file object (though so far you have only been interested in anonymous, and now shmem). A better patch would say: - if (flags & MREMAP_DONTUNMAP && (!vma_is_anonymous(vma) || - vma->vm_flags & VM_SHARED)) + if ((flags & MREMAP_DONTUNMAP) && + (vma->vm_flags & (VM_DONTEXPAND | VM_PFNMAP))) return ERR_PTR(-EINVAL); VM_DONTEXPAND is what has long been used on special mappings, to prevent surprises from mremap changing the size of the mapping: MREMAP_DONTUNMAP introduced a different way of expanding the mapping, so VM_DONTEXPAND still seems a reasonable name (I've thrown in VM_PFNMAP there because it's in the VM_DONTEXPAND test lower down: for safety I guess, and best if both behave the same - though one says -EINVAL and the other -EFAULT). With that VM_DONTEXPAND check in, Dmitry's commit cd544fd1dc92 ("mremap: don't allow MREMAP_DONTUNMAP on special_mappings and aio") can still be reverted (as you agreed on 28th December), even though vma_is_anonymous() will no longer protect it. Was there an mremap(2) man page update for MREMAP_DONTUNMAP? Whether or not there was before, it ought to get one now. Thanks, Hugh