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 05209C433F5 for ; Sun, 19 Dec 2021 21:28:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F06F46B0071; Sun, 19 Dec 2021 16:27:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB5896B0073; Sun, 19 Dec 2021 16:27:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D56AE6B0078; Sun, 19 Dec 2021 16:27:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0088.hostedemail.com [216.40.44.88]) by kanga.kvack.org (Postfix) with ESMTP id C6B126B0071 for ; Sun, 19 Dec 2021 16:27:52 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7A81F8A3C4 for ; Sun, 19 Dec 2021 21:27:36 +0000 (UTC) X-FDA: 78935830512.28.53D346C Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf11.hostedemail.com (Postfix) with ESMTP id BC57A40037 for ; Sun, 19 Dec 2021 21:27:33 +0000 (UTC) Received: by mail-ed1-f47.google.com with SMTP id z5so30640893edd.3 for ; Sun, 19 Dec 2021 13:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZOShkgSsLUNxxfuqCgeDeOt2ke5//N9VVujAkHreXEg=; b=LqNmclrkwQCsbrNtIezCKp85izX4onfAiRFTRfPRPGRgPokTZlM7X1drmL6HICY2j9 at/rEpYzr4ZXWvvP4fbrIrue8KwptDf7MKxC0s6vNlZujg3zNB3SersC3KyFG+JHqT3n b1+ZTJUiCalTiCm+t2714XkqPnvEoRzVbU9PY= 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=ZOShkgSsLUNxxfuqCgeDeOt2ke5//N9VVujAkHreXEg=; b=xiF6sixbirToW3BYJnVa5cs+1ODWUBrnJr+DNj1QlBTtLIA3+3MRdBrTKs8RFnI1fb gUFhOcg0JcS/1CedkAdKGQvxLMINexD+iqQYZl1LIXmxpWDR2skho0J6Wjjw4AoQeV2T FSIqDBOGgtM9t4yo/UeDscw3YvaikIscP0MeKBobIQsLRmUh5zkMKqOO3b8HCPhqbNp7 rD0C9QtRZqRLdWgfFDZaQMTECQTp5DL8SEUOFS1hcKf9ja95BeKrYkjCxXfAYl87HYMu 4NO9e+iWQFVanodHW8v8vQK6vJKGnVKmQcz2cnXM5ofcfttJwJJv1sgFUpeez7jwYhDj maUA== X-Gm-Message-State: AOAM530CREaTBV36jkdE6uGE1mWdsk4DbdEq2kI7sBHE1/9/dMKcY+wB G//xGYfttB/XtENkX4drjxJ1LIw6tGXFGdRqzuI= X-Google-Smtp-Source: ABdhPJxshdFJFuTF49FmDAAGurFW3bvmiur49Cck5xWDnC8i7pTh/YX0FnDRmmicCdnJE0U4b3xxXA== X-Received: by 2002:a17:906:7310:: with SMTP id di16mr10567721ejc.92.1639949254450; Sun, 19 Dec 2021 13:27:34 -0800 (PST) Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com. [209.85.221.46]) by smtp.gmail.com with ESMTPSA id e4sm4903065ejs.13.2021.12.19.13.27.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Dec 2021 13:27:34 -0800 (PST) Received: by mail-wr1-f46.google.com with SMTP id j9so16242751wrc.0 for ; Sun, 19 Dec 2021 13:27:34 -0800 (PST) X-Received: by 2002:adf:8b0e:: with SMTP id n14mr10364723wra.281.1639949243461; Sun, 19 Dec 2021 13:27:23 -0800 (PST) MIME-Version: 1.0 References: <20211218184233.GB1432915@nvidia.com> <5CA1D89F-9DDB-4F91-8929-FE29BB79A653@vmware.com> <4D97206A-3B32-4818-9980-8F24BC57E289@vmware.com> <5A7D771C-FF95-465E-95F6-CD249FE28381@vmware.com> In-Reply-To: From: Linus Torvalds Date: Sun, 19 Dec 2021 13:27:07 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) To: Matthew Wilcox Cc: David Hildenbrand , Nadav Amit , Jason Gunthorpe , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Vlastimil Babka , Jann Horn , Michal Hocko , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: u6bo61hzhhn41bx1pynunj6p8r816gfx X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BC57A40037 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=LqNmclrk; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.47 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1639949253-303220 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, Dec 19, 2021 at 1:12 PM Matthew Wilcox wrote: > > Can we get rid of ->mapcount altogether? Three states: > - Not mapped > - Mapped exactly once > - Possibly mapped more than once I don't think even that is useful. We should get rid of mapcount entirely. It doesn't actually help to know "mapped exactly once", exactly because even when that's true, there may be non-mapped references to the page. Mapped references really aren't that special in general. One case where it *can* be special is on virtually indexed cache architectures, where "is this mapped anywhere else" can be an issue for cache flushing. There the page_mapcount() can actually really matter, but it's such an odd case that I'm not convinced it should be something the kernel VM code should bend over backwards for. And the count could be useful for 'rmap' operations, where you can stop walking the rmap once you've found all mapped cases (paghe migration being one case of this). But again, I'm not convinced the serialization is worth it, or that it's a noticeable win. However, I'm not 100% convinced it's worth it even there, and I'm not sure we necessarily use it there. So in general, I think page_mapcount() can be useful as a count for those things that are _literally_ about "where is this page mapped". Page migration, virtual cache coherency, things like that can literally be about "how many different virtual mappings can we find". It's just that pages can have a number of non-mapped users too, so mapcount isn't all that meaningful in general. And you can look it up with rmap too, and so I do think it would be worth discussing whether we really should strive to maintain 'mapcount' at all. > I appreciate "Not mapped" is not a state that anon pages can > meaningfully have (maybe when they go into the swap cache?) Absolutely. And we can keep references around to an anonymous page even without it having any mapping or swap cache at all (ie "gup + unmap"). So "Not mapped at all" is a possible case, without the page being free'd. Linus