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 A1434C636CD for ; Tue, 7 Feb 2023 04:08:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DCDA46B0071; Mon, 6 Feb 2023 23:08:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7D626B0073; Mon, 6 Feb 2023 23:08:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6D826B0074; Mon, 6 Feb 2023 23:08:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B5F0B6B0071 for ; Mon, 6 Feb 2023 23:08:43 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8DA0F80700 for ; Tue, 7 Feb 2023 04:08:43 +0000 (UTC) X-FDA: 80439164526.20.787D922 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id DCC8A40007 for ; Tue, 7 Feb 2023 04:08:41 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=hRBxF5LP; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675742922; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=SAAj7RiVgNZvrhR6JMCA5zx2KxH7RXO31fSAYQJEaac=; b=CWRg0m3cXfBvO1ZNRzFFB2BMB5g8JsQQGRTV5rTe55KRYOMw82d5Y45qXKDik0AbDKBNlC 6VnD0pCokXmVM7WONV0kelJ2nrNBgD0ReRmadInw8kUQxQLjq05OcXH0Ib/MS7HCW0nKK9 De0wFUOWDmGuPr75vGTW8C2XM1CRU70= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=hRBxF5LP; dmarc=none; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675742922; a=rsa-sha256; cv=none; b=YXhLv2qHJvldkpvFzh1f8nWkapfnNlMCn59Y+A8UV7mR5kg3ndkcWfV+NsGtfdDI90cqVu NxCIKGgb38FBGH/tmWijDw92jgFBoySpYMKsx1BRX7sRDiJLKnratA1OmtveFSgJ1NV1ht lDegPOSOAtq5Uuk/WsHWxPmb/2Ui3OE= 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=SAAj7RiVgNZvrhR6JMCA5zx2KxH7RXO31fSAYQJEaac=; b=hRBxF5LPg+up08D5um9HPzLe7n e99oKpa0pkVmUO27FQJo6/rx0OSBFDmhu5qxTlTOsaf5IzxgFaB6cQTlfB/f1HUGVaRSimhj3egal fEhGizzqpXKO+R8wvZplJx562U7KRoXUALkVZdQ8St4OwAxAfykRnTlcrmKZLMjJd4eSRwRM7l5Yn Q6+hvQqjD1VFZiJtCHBzIv/Lsk6VL5UO0CBL3bBMvRozkgB1UjXh42Kfddofqf4yosCmJTt6Nr+5e 5B1bjbVE6XQZrMYufyB193LcScfKDFJ6aUKQ2gmcB95azDFfXnXNdehWeCUOvdqZNX44nK21iIY+q 5ei04vsA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pPFHX-00HRKM-FR; Tue, 07 Feb 2023 04:08:35 +0000 Date: Tue, 7 Feb 2023 04:08:35 +0000 From: Matthew Wilcox To: "Yin, Fengwei" Cc: linux-mm@kvack.org, Vishal Moola , Hugh Dickins , Rik van Riel , David Hildenbrand Subject: Re: Folio mapcount Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DCC8A40007 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: kahw8dztc9m97bkrjgo39mff1t4xt6sr X-HE-Tag: 1675742921-592000 X-HE-Meta: U2FsdGVkX19Gehj6arkqYS7SmeESikIdbjGWPUwdPdzqOBlUU8Y4GUtaTmuhXSQ/6AWOks8aapXHhDKJJY5tvyAqPYLkmyBsaufgfmJBmuuuI8rfRCdxW9GYrNRkSMoWkkYg5mWD1SFeDSgFCY2E7vMXczrRCq4mnN6y8rCW654bEptLS73+pddikXNrKd6pJBzv7k/PU4E+MMC2DRZOwDfGCXPT5mjqDIu4+A95Bkny08P1CMEDy6abrTlojvzpoE4MZFYo2RacGCyx+QxXC4hLCIl9LiUSM+2JeTm5fLSUridyBBiv15hS105taewqUKPhPhu8LADNG11waqABmN6vjZaWJH6jb62GKSYmMtH55IYkt1ZogoXmkS3aNW1zaLyF9Nhn1GBkPkSnpbWEhyztDbiGuvhtzqh9Fj8FBlwYvyPTPTqAZqueYCCNDrJJvd6nT6mKPEvT068YLMA1QGc0fpd4GC7LBsR7zcQC651V6k1QtpVStjFdA6Q2HLNLKBb5hKMbQf+DGICV+Sentogj4whV8bHyWM3DItIR5n/plmeCG/x+U+usLKmpiKE/znOiaymRAhmJd/1wt8Yl+g0OUdiYVMiT4bUYArElEI+2MLHQL53EqMqrzCJI07ubG5UEw+wJXnltG7uUNnAaKDy764W0fH5CXsXLo4FeyPt2nePse01mtWav/EqLhXTrybFPP1QJ7fbaNETBstWNsWcNjrn5YbE4vXauxrqY3bfsQ0uS43nkPklqyRXy3Z2Z2dgJhpwe16U7z6oeZsX4r+2g/LH257D6pyvZHIFZfdwhTcYO5I+E86aBnatWU45dgax/2U7uSwtUspQ8dfMmbqjkXFjdCmqFyWasQZViGChoq1EYGP6qD6CjRTpxYWrykHIBzT+vWLYNE060XKexLeVVjgfhyGhd8Tg/BsANwISFVxdldZwkRDfy8fOIM+wh7qAhohVkPc6Bqx0YDtZ Y0j2Ifjb C0tJ6gKJKqB90BodOzWDBtuGQADzo9nP5qb32lDo9MMmwbfApI/MK5nZmPfkIR3j9nXv/Yd7iF9fSGOwXa2uyV9U03DZYa+zdJmw6FpA4RMjBB6+kkk5dl3bqxLQDE0DM0Cs2xlF72Ghu70iJxDukK/RMk78XJvTyqQvCXSBjuw8ONnct215p5RGaiwMCQ/HqhHbflT4N+mqqSHrrCsYpodQIzna/tHrGOyMK 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, Feb 07, 2023 at 11:06:13AM +0800, Yin, Fengwei wrote: > On 2/7/2023 4:34 AM, Matthew Wilcox wrote: > > On Tue, Jan 24, 2023 at 06:13:21PM +0000, Matthew Wilcox wrote: > >> Once we get to the part of the folio journey where we have > >> one-pointer-per-page, we can't afford to maintain per-page state. > >> Currently we maintain a per-page mapcount, and that will have to go. > >> We can maintain extra state for a multi-page folio, but it has to be a > >> constant amount of extra state no matter how many pages are in the folio. > >> > >> My proposal is that we maintain a single mapcount per folio, and its > >> definition is the number of (vma, page table) tuples which have a > >> reference to any pages in this folio. > > > > I've been thinking about this a lot more, and I have changed my > > mind. It works fine to answer the question "Is any page in this > > folio mapped", but it's now hard to answer the question "I have it > > mapped, does anybody else?" That question is asked, for example, > > in madvise_cold_or_pageout_pte_range(). > > > > With this definition, if the mapcount is 1, it's definitely only mapped > > by us. If it's more than 2, it's definitely mapped by somebody else (*). > > If it's 2, maybe we have the folio mapped twice, and maybe we have it > > mapped once and somebody else has it mapped once, so we have to consult > > the rmap to find out. Not fun times. > Naive question: If it's 2, why do we need to know whether it's mapped twice > by us or one by us and one by somebody else? Does that mean we allow some > operations if only us mapped it even it's 2? Thanks. Yes, see the aforementioned madvise_cold_or_pageout_pte_range(): (in mainline, it's different in -next): /* Do not interfere with other mappings of this page */ if (page_mapcount(page) != 1) goto huge_unlock;