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=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 BFC61C433E1 for ; Thu, 13 Aug 2020 22:04:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7F91820829 for ; Thu, 13 Aug 2020 22:04:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="hP/t3zNt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F91820829 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 224568D0007; Thu, 13 Aug 2020 18:04:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AD298D0003; Thu, 13 Aug 2020 18:04:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 09BC28D0007; Thu, 13 Aug 2020 18:04:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id E65618D0003 for ; Thu, 13 Aug 2020 18:03:59 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 9E0855DFB for ; Thu, 13 Aug 2020 22:03:59 +0000 (UTC) X-FDA: 77146923798.16.light49_051376a26ff7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 69FAA100E6903 for ; Thu, 13 Aug 2020 22:03:59 +0000 (UTC) X-HE-Tag: light49_051376a26ff7 X-Filterd-Recvd-Size: 4904 Received: from mail-ua1-f66.google.com (mail-ua1-f66.google.com [209.85.222.66]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Thu, 13 Aug 2020 22:03:59 +0000 (UTC) Received: by mail-ua1-f66.google.com with SMTP id e20so2108115uav.3 for ; Thu, 13 Aug 2020 15:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EsbHMQJeNL+c6Uza7hvN4P77fBQm57qJp2Sf89wf1ws=; b=hP/t3zNteVZR5tcE4K2tgxbfsbyqTwjwjTIoYfpPLrGiHYAnoOwXwECk3fSMNkeTWa 7KCwhy8yh2QNiy1AzvH7f18x36oODvUcyeVfx6yDayJAtQLchdHByru81Gvufq77GrY1 Mt+vPPaP6ftGBJJSo9gx/0maxF+yy9Thph0aGP/K3ZGdGRfjF2fm0NPFcph2+M9IaXs0 QgMK0f4MY3zKxDfUdKLJIFLA8fxIIkdfTZ0jF0ezpnStdpfZbwD+UQq49Qh1YSZlCEtn B583zxBHn2pIVSgUuxjG0DxZTGMTbTIrR5rc9P71J+GtIjQqSKz4Hd2Ej3/NNVd9P+TW 9K3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EsbHMQJeNL+c6Uza7hvN4P77fBQm57qJp2Sf89wf1ws=; b=UXXlz/6oV/WqsNiMDefaN2r/XTqhmxdv1wiqu8gyZPvChUWtkdF8lagyfiY7/YqCMM JKkCw3XFgbJGRtkmD7wqYfpExkVdkBiOuv48efl0aADg7qDaBo0rFpwIUufIJsj5eF5Q PrwOxDgQdX4au9r0vWk7/jrGPcBEUIKituqNnEIx7drwiT5IZUr6pN5Mw9zGZRkIYqH8 pJOjk6EP1zRQoo/q2LONs4hgny3darqMIM5mAoRAR9hs25l6Fv4LI+peiVq6aRVT2gsq tbPqYUDvlm8cwsWdP9V2+gzxjA1dmgERqdk6XYH3KCE/mSnrCfkez3DQHmi+S7kWnX4g 5C/Q== X-Gm-Message-State: AOAM5308qHinLZDrEWelhfKkTRYuNqSTq8iPjt4Ol470GRfvxmFI5c/1 BodlNh2p+mP5gb3YQbTm3/8RTAe2b1N/DHdpf/ftYA== X-Google-Smtp-Source: ABdhPJyeAKTqqwqbUpRpe93wJUoyh/OvlDy1UikwelBAcD/YwjuMRLCIJIu+jufldjcP4kYTc1U1t2IZETL/QS3W+K8= X-Received: by 2002:ab0:1892:: with SMTP id t18mr5275109uag.108.1597356238297; Thu, 13 Aug 2020 15:03:58 -0700 (PDT) MIME-Version: 1.0 References: <20200731203241.50427-1-pcc@google.com> <92fa4a71-d8dc-0f07-832c-cbceca43e537@nvidia.com> <20200803035113.GX23808@casper.infradead.org> In-Reply-To: <20200803035113.GX23808@casper.infradead.org> From: Peter Collingbourne Date: Thu, 13 Aug 2020 15:03:47 -0700 Message-ID: Subject: Re: [PATCH] mm: introduce reference pages To: Matthew Wilcox Cc: John Hubbard , Andrew Morton , Catalin Marinas , Evgenii Stepanov , Linux ARM , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 69FAA100E6903 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 Sun, Aug 2, 2020 at 8:51 PM Matthew Wilcox wrote: > > On Sun, Aug 02, 2020 at 08:28:08PM -0700, John Hubbard wrote: > > This will end up overflowing the page->_refcount in some situations. > > > > Some thoughts: > > > > In order to implement this feature, the reference pages need to be made > > at least a little bit more special, and probably little bit more like > > zero pages. At one extreme, for example, zero pages could be a special > > case of reference pages, although I'm not sure of a clean way to > > implement that. > > > > > > The reason that more special-ness is required, is that things such as > > reference counting and locking can be special-cased with zero pages. > > Doing so allows avoiding page->_refcount overflows, for example. Your > > patch here, however, allows normal pages to be treated *almost* like a > > zero page, in that it's a page full of constant value data. But because > > a refpage can be any page, not just a special one that is defined at a > > single location, that leads to problems with refcounts. > > We could bump the refcount on mmap and only put it on munmap. That > complexifies a few more paths which now need to check for the VMA special > page as well as the zero page on pte unmap. > > Perhaps a better way around this is that the default page can only be one > of the pages in the mmap ... and that page is duplicated (not shared) on > fork(). That way the refcount is at most the number of pages in the mmap. > And if we constrain the size of these mappings to be no more than 8TB, > that constrains the refcount on this page to be no more than 2^31. I'm not a fan of this idea to be honest. It means that we need to spend a page per mapping to get this behavior, instead of a page across the entire process. And in an allocator like scudo we can end up making a lot of mappings. I think there would also be complexities around VMA splitting, which would probably mean that these mappings become special enough that we don't gain much with this approach. Thanks, Peter