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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7851C433EF for ; Wed, 12 Jan 2022 03:33:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FB3C6B0116; Tue, 11 Jan 2022 22:33:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3AA496B0117; Tue, 11 Jan 2022 22:33:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 298456B0118; Tue, 11 Jan 2022 22:33:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 166016B0116 for ; Tue, 11 Jan 2022 22:33:57 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BB7CF180998C0 for ; Wed, 12 Jan 2022 03:33:56 +0000 (UTC) X-FDA: 79020216072.04.8447B06 Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf22.hostedemail.com (Postfix) with ESMTP id 467B6C000D for ; Wed, 12 Jan 2022 03:33:56 +0000 (UTC) Received: by mail-ed1-f48.google.com with SMTP id w16so4320600edc.11 for ; Tue, 11 Jan 2022 19:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uYq312tqKbOg7PFLNwXB0CwSYMigHjxwSWqrvkkYJTQ=; b=Wff6miex+nOrTZ0fO19HXqe39gIw+2MbRg0oGLxv6kz3aCdrvz+Fr724v4uhRiM5KM 80Pd4P5gQ6wqmtDCOq/0Ii9g08vNeCSMhiEEGJPKctjvj6QE6KzMW5iPUJVfJYM9IrTB POVmWhzW/h9Efq3GN9FFK4teCFl3JTyVbJpmus1BsZcpex971DgBPRm6jxLZX4lR+vPx EifF87oOkeGRIagEuSZhy19VH0OuLZbzEMdU3edvKeplR5P4mfN6IVxfDxpUlTwBKrfa k2UV8nk5k/bD1hwSxycxSCDcSp4x/VmcJ1iNOi9QRDoGMwmmv3pEf80hVh8vFN/IDVX1 IKmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uYq312tqKbOg7PFLNwXB0CwSYMigHjxwSWqrvkkYJTQ=; b=KqYKTqAddafq9sUCIBsgQwvGJlZzXLy/mnjgrzSSITJ8vYMH4LlAxknne9NoPJ2bfh KY9PUSU92CedCW8dCJlPRB4L3oHlgxd1dZ1btDGx6FQ7s9+p/GQ+xZLZ3K6Zf4MZI4Yo rsWKRBhfuRYoJATQeMaqPv0zfbQYpKeM2nnFslRyoRqVRkf7QYpiejQWK/DMzboQZeA5 kVavIb5LpqmRg5jl6J/rlUmvNv6MBSPabGscSyMkSoZBT28HDsHtdEJo16IUusjlExbM WEZfJX0b8oJ/AUvzOxXH3UzKxI2zzyQb7Qga2nOVIevZic/nY6QuqFbI7/Nkmy2vnWnC 48sw== X-Gm-Message-State: AOAM532QdtModWQ66grG4OzDXO3R08O+znRjhwlmcx1LEKK55SzmQQzg SAfYd7FEzPBZWvDLSWczsMj4VT72VOGmVu+rtwQ= X-Google-Smtp-Source: ABdhPJzQv5Jr3gKu995OPL6/o8CeAIlzcDtjgl4pDJqC60kJl/jM6lj9pkviuwvMh7Wdz51+zQ/LQpIJd6glaP8mAnU= X-Received: by 2002:a05:6402:11c9:: with SMTP id j9mr7039854edw.385.1641958434997; Tue, 11 Jan 2022 19:33:54 -0800 (PST) MIME-Version: 1.0 References: <20211222123400.1659635-1-liangpeng10@huawei.com> <4b1885b8-eb95-c50-2965-11e7c8efbf36@google.com> In-Reply-To: <4b1885b8-eb95-c50-2965-11e7c8efbf36@google.com> From: Yang Shi Date: Tue, 11 Jan 2022 19:33:42 -0800 Message-ID: Subject: Re: [RFC 0/1] memfd: Support mapping to zero page on reading To: Hugh Dickins Cc: Peng Liang , David Hildenbrand , Linux MM , Linux Kernel Mailing List , Andrew Morton , xiexiangyou@huawei.com, zhengchuan@huawei.com, wanghao232@huawei.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 467B6C000D X-Stat-Signature: zcp85wm3tepqcdq98t5k1f68jhah3bz9 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Wff6miex; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.48 as permitted sender) smtp.mailfrom=shy828301@gmail.com X-Rspamd-Server: rspam06 X-HE-Tag: 1641958436-745080 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 Tue, Jan 11, 2022 at 6:30 PM Hugh Dickins wrote: > > On Wed, 22 Dec 2021, Peng Liang wrote: > > > Hi all, > > > > Recently we are working on implementing CRIU [1] for QEMU based on > > Steven's work [2]. It will use memfd to allocate guest memory in order > > to restore (inherit) it in the new QEMU process. However, memfd will > > allocate a new page for reading while anonymous memory will map to zero > > page for reading. For QEMU, memfd may cause that all memory are > > allocated during the migration because QEMU will read all pages in > > migration. It may lead to OOM if over-committed memory is enabled, > > which is usually enabled in public cloud. > > > > In this patch I try to add support mapping to zero pages on reading > > memfd. On reading, memfd will map to zero page instead of allocating a > > new page. Then COW it when a write occurs. > > > > For now it's just a demo for discussion. There are lots of work to do, > > e.g.: > > 1. don't support THP; > > 2. don't support shared reading and writing, only for inherit. For > > example: > > task1 | task2 > > 1) read from addr | > > | 2) write to addr > > 3) read from addr again | > > then 3) will read 0 instead of the data task2 writed in 2). > > > > Would something similar be welcome in the Linux? > > David has made good suggestions on better avoiding the need for > such a change, for the use case you have in mind. > > And I don't care for the particular RFC patch that you posted. > > But I have to say that use of ZERO_PAGE for shmem/memfd/tmpfs read-fault > might (potentially) be very welcome. Not as some MFD_ZEROPAGE special > case, but as how it would always work. Deleting the shmem_recalc_inode() > cruft, which is there to correct accounting for the unmodified read-only > pages, after page reclaim has got around to freeing them later. I'm wondering if we could use ZERO_PAGE for shmem_getpage() too so that we have simpler return value? Currently shmem_getpage() returns: #1. errno and NULL *pagep #2. 0 and valid *pagep #3. 0 and NULL *pagep if SGP_READ Using ZERO_PAGE should be able to consolidate #2 and #3 so that we know there must be valid *pagep if 0 is returned. This should make read-fault use ZERO_PAGE automatically. > > It does require more work than you gave it in 1/1: mainly, as you call > out above, there's a need to note in the mapping's XArray when ZERO_PAGE > has been used at an offset, and do an rmap walk to unmap those ptes when > a writable page is substituted - see __xip_unmap() in Linux 3.19's > mm/filemap_xip.c for such an rmap walk. > > Though when this came up before (in the "no-fault mmap" MAP_NOSIGBUS > thread last year - which then got forgotten), Linus was wary of that > unmapping, and it was dropped for a simple MAP_PRIVATE implementation. > > And I've never scoped out what is needed to protect the page from > writing in all circumstances: in principle, it ought to be easy by > giving shmem_vm_ops a page_mkwrite; but that's likely to come with > a performance penalty, which may not be justified for this case. > > I didn't check what you did for write protection: maybe what you > did was enough, but one has to be very careful about that. > > Making this change to ZERO_PAGE has never quite justified the effort > so far: temporarily allocated pages have worked well enough in most > circumstances. > > Hugh > > > > > Thanks, > > Peng > > > > [1] https://criu.org/Checkpoint/Restore > > [2] https://patchwork.kernel.org/project/qemu-devel/cover/1628286241-217457-1-git-send-email-steven.sistare@oracle.com/ > > > > Peng Liang (1): > > memfd: Support mapping to zero page on reading memfd > > > > include/linux/fs.h | 2 ++ > > include/uapi/linux/memfd.h | 1 + > > mm/memfd.c | 8 ++++++-- > > mm/memory.c | 37 ++++++++++++++++++++++++++++++++++--- > > mm/shmem.c | 10 ++++++++-- > > 5 files changed, 51 insertions(+), 7 deletions(-) > > > > -- > > 2.33.1 >