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=-4.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 5F8BCC433E0 for ; Mon, 3 Aug 2020 09:32:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E69B206D7 for ; Mon, 3 Aug 2020 09:32:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=shutemov-name.20150623.gappssmtp.com header.i=@shutemov-name.20150623.gappssmtp.com header.b="AE7BGOYG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E69B206D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 51B668D00F4; Mon, 3 Aug 2020 05:32:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CC8C8D00E9; Mon, 3 Aug 2020 05:32:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E3558D00F4; Mon, 3 Aug 2020 05:32:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) by kanga.kvack.org (Postfix) with ESMTP id 29A8D8D00E9 for ; Mon, 3 Aug 2020 05:32:56 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B299F2C0D for ; Mon, 3 Aug 2020 09:32:55 +0000 (UTC) X-FDA: 77108743110.07.noise57_240376b26f9c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 8A2781803F9A3 for ; Mon, 3 Aug 2020 09:32:55 +0000 (UTC) X-HE-Tag: noise57_240376b26f9c X-Filterd-Recvd-Size: 5564 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Mon, 3 Aug 2020 09:32:55 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id m15so19437023lfp.7 for ; Mon, 03 Aug 2020 02:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mcQI0cC775Sd04iZMIrBeKr+uEG11QbMPcE3c59G3+8=; b=AE7BGOYGIoNiwD5gLMrVBS8icv4i/EEeEs02gUeqKScTO2DxzQ6JHI8J85wd841hsR DjXHErfNfzVICUt1c6wdd8YjLuPax6Jbw5FoG93BwQVTsN0RxVBZ847jteiSQ+LxmlQD oi/bmk9kgZY/fHueFfwvXBDbLrsw8Vd3XdBp7Exw5yGbkkXgLcIbvuLXoB9uVkwcF2My RJxyg5BOnqOzpB9ySF1k4OeFgxxutpSAp+l3b1K7AkR4bXjWmhZakT6HgO3ZzRpvdwJO pbsceHyh9NbHHgz9ccmFAFmC/xfeOhXP4ykyxaOoM7TGl6JF+fKliwt9fFYFERZZZ7MD 70Eg== 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:in-reply-to; bh=mcQI0cC775Sd04iZMIrBeKr+uEG11QbMPcE3c59G3+8=; b=ECfikNWFG4A2eNKmt9dW1IHXGY9f1CjiEEj9Q/HoO4iGbbn5LGUraIvYpy2KS4M8Dd L7SeYDJhiOoCGWjK+iKuFSYvKWBi12F1C068Y2HArl8MkeN0Z8MpFzSBP3I1BK2z+FHu jtq0ILvTChkV3TEWF5fWijp5h+FFKY5mFFxYlBVLM6f9G6joSTJbXR9SujWKSSB2GH/Z vEhH8ZXW22m6BiiLoD6Au2OOt2vjM+vxm3ude73lV9uq165YDbDkVzWHOQBDPuaGoX9S lCs4N3XJ7d13D0rb+cSIb44JM5jf0u869dSkF2TDqHtczzhy6VcR/qaYryL1ibHeUdU7 Xdcw== X-Gm-Message-State: AOAM533d4ekMGRJNPUMPpd5orJJ08r/qEtgoqS0K2zP3p/CkO+fFWOLo Zv08fZYiiW6AXrPR+R8FBFHDNuA1wYQ= X-Google-Smtp-Source: ABdhPJyNfssvlofacXd0vdtqby+h8tUvpSBXJJ9IMENqabOypsf3Klky5WxWuAFteyC0b+Jp/tnOpA== X-Received: by 2002:ac2:488c:: with SMTP id x12mr7619304lfc.4.1596447173545; Mon, 03 Aug 2020 02:32:53 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id v11sm4004247ljh.119.2020.08.03.02.32.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2020 02:32:52 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 05B02101674; Mon, 3 Aug 2020 12:33:00 +0300 (+03) Date: Mon, 3 Aug 2020 12:32:59 +0300 From: "Kirill A. Shutemov" To: Peter Collingbourne Cc: Andrew Morton , Catalin Marinas , Evgenii Stepanov , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH] mm: introduce reference pages Message-ID: <20200803093259.ookknl4y7ee5hun7@box> References: <20200731203241.50427-1-pcc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200731203241.50427-1-pcc@google.com> X-Rspamd-Queue-Id: 8A2781803F9A3 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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, Jul 31, 2020 at 01:32:41PM -0700, Peter Collingbourne wrote: > Introduce a new mmap flag, MAP_REFPAGE, that creates a mapping similar > to an anonymous mapping, but instead of clean pages being backed by the > zero page, they are instead backed by a so-called reference page, whose > address is specified using the offset argument to mmap. Loads from > the mapping will load directly from the reference page, and initial > stores to the mapping will copy-on-write from the reference page. > > Reference pages are useful in circumstances where anonymous mappings > combined with manual stores to memory would impose undesirable costs, > either in terms of performance or RSS. Use cases are focused on heap > allocators and include: > > - Pattern initialization for the heap. This is where malloc(3) gives > you memory whose contents are filled with a non-zero pattern > byte, in order to help detect and mitigate bugs involving use > of uninitialized memory. Typically this is implemented by having > the allocator memset the allocation with the pattern byte before > returning it to the user, but for large allocations this can result > in a significant increase in RSS, especially for allocations that > are used sparsely. Even for dense allocations there is a needless > impact to startup performance when it may be better to amortize it > throughout the program. By creating allocations using a reference > page filled with the pattern byte, we can avoid these costs. > > - Pre-tagged heap memory. Memory tagging [1] is an upcoming ARMv8.5 > feature which allows for memory to be tagged in order to detect > certain kinds of memory errors with low overhead. In order to set > up an allocation to allow memory errors to be detected, the entire > allocation needs to have the same tag. The issue here is similar to > pattern initialization in the sense that large tagged allocations > will be expensive if the tagging is done up front. The idea is that > the allocator would create reference pages with each of the possible > memory tags, and use those reference pages for the large allocations. Looks like it's wrong layer to implement the functionality. Just have a special fd that would return the same page for all vm_ops->fault and map the fd with normal mmap(MAP_PRIVATE, fd). It will get you what you want without touching core-mm. -- Kirill A. Shutemov