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,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 17875C433E0 for ; Mon, 3 Aug 2020 03:52:46 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DB3402075A for ; Mon, 3 Aug 2020 03:52:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rF4Jc8RK"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Z5WVfGWo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DB3402075A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Wkvf4++vVeTzl8Ksqw8jfdFKc20eTUt2aDCdMaJ4P0Q=; b=rF4Jc8RKrh5RD6PUjmzuD7UbG FHFYiU3cve4Mu22NDJTvmMtb/i5PQQhDZWTuvVtYS8v/2niPWnfcQS4mPDE6fTG8JiR5GtxExaoJP a6RW1CdQkAMF/g5vxBt0OFBEyt3Lsd80mp1WQA9K+PYOHXq6qBcUe1+/Ahqx6JqQQV5cKMsrhLJAW e7YbfJ5QJDk8jQWb6Gm+VLP65Aw2/FnN/qHeAFmf8aKMJmOkQRWPn1LgUeQePcP5GDSAaE0SeNZIq P9RprbqZJCV8nLsveLJxAKhP169DrRXdcb2F/Dg4laOp4vxkrj3bxtURJ2CbP5G+efCHtmARWF32h gjRHq7LRA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2RVN-0004vu-IL; Mon, 03 Aug 2020 03:51:17 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2RVL-0004vl-SA for linux-arm-kernel@merlin.infradead.org; Mon, 03 Aug 2020 03:51:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=8I3DaixdTox8M5PB85ZtuTeAJfxo74UHSwaDKrGgINE=; b=Z5WVfGWoWoC7TbrxqL63Kjx9A/ XcLQyHtwHj31skWxKNYftk6ZhWXafzjMIWR/dz1/RW19UmNy/crQQg/oxNvOvfYIgGDOyQPZblqtN rMq1kPGqOqs4UUlcjv91AxIYhPSSvQN4vMDBWOhGTwUjTPojiwjchiNGsNS9fkuJAeNSVCm9zBYGW 3MHqmwJ+U7gWObSfXTxUjurmIrcG5p9j8bMYemnAyBcMHtHZ7Pfpekh67L4/Fldgylf/6cf1vBIzb r0dbZZfewbS5Qwm6JC25fQpZt8BAP7oVxTlo8706Ng1S0/hTPZRKgEWcdfhISK+pa9LPnJAy5JNmN tpDGLpsw==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2RVK-0005I3-1Z; Mon, 03 Aug 2020 03:51:14 +0000 Date: Mon, 3 Aug 2020 04:51:13 +0100 From: Matthew Wilcox To: John Hubbard Subject: Re: [PATCH] mm: introduce reference pages Message-ID: <20200803035113.GX23808@casper.infradead.org> References: <20200731203241.50427-1-pcc@google.com> <92fa4a71-d8dc-0f07-832c-cbceca43e537@nvidia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <92fa4a71-d8dc-0f07-832c-cbceca43e537@nvidia.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , linux-mm@kvack.org, Evgenii Stepanov , Andrew Morton , Peter Collingbourne , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel