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=-3.8 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 403C3C433EF for ; Thu, 23 Sep 2021 12:45:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8F6F6115A for ; Thu, 23 Sep 2021 12:45:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D8F6F6115A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shutemov.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7E2EF6B006C; Thu, 23 Sep 2021 08:45:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76B3C940008; Thu, 23 Sep 2021 08:45:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60BA0940007; Thu, 23 Sep 2021 08:45:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 4F18F6B006C for ; Thu, 23 Sep 2021 08:45:04 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 1025E1812D470 for ; Thu, 23 Sep 2021 12:45:04 +0000 (UTC) X-FDA: 78618808128.14.849F8F2 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) by imf11.hostedemail.com (Postfix) with ESMTP id AEB22F0000BD for ; Thu, 23 Sep 2021 12:45:03 +0000 (UTC) Received: by mail-lf1-f50.google.com with SMTP id p29so25798772lfa.11 for ; Thu, 23 Sep 2021 05:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=DLm/JPaMIp6sjkaiuRZT1UExfCGgcFfeWo4FyZBtSmY=; b=C0MDMxtYtfwEmfvJywxjNgCnSRV1IuOYywW30v5Q3V9tB/M1aIo+IL5+rjhfuO2TN5 fMvGamX4epVIpdX+CpP8rU6rJNm/tJzqhXDiGoNzoUD9ytFoJAcBIK7l6FCZc1jZYZCe ZD4DjQAdQG/JJ0onl/YbliWqsLTG+3CsAkeDyRC3w++Z8+A8Wj+hEvRQvjF7hA/a1/mB Q0GA4tbppZBSJzskdVLbtv4tU7ZK8PqWAH9lbnngCzcy8DcGq9eSMFS5/8ENNmtTCCsB 8e4dS0e5WZ3eJrTXAvSxkUkwFFLtuv+RLMg25F5mXXZrSpuW6L0n75ltFTPCmt2D2Kto aPgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=DLm/JPaMIp6sjkaiuRZT1UExfCGgcFfeWo4FyZBtSmY=; b=fYqr5m7F/c6TshjOzYKkRhij0iS6tx3CZXs5aylXYevuCdLQdbhdK8Erp9d+xtvLkw Stnb/0opkQ+GE3z1m3chx66ihPhPHkmGXpVqyxIpdVKix9bJfpHWXBBAM6Zn/oGlYBjm +ssmgVf8kpu3sLa5JqhsnenuR8+VajSSqGXr+iSd+5xk3/vWYXm1iulBLufg3nhEfKpM wMXL6hEvE1JCi4DMF18gkD2C0pYg8cRfBBAQ2zjUxxmLP58HSNwslmiTpOscHa+x/8kq FrvP3+53ZNVH6mwO1CVyJvsySct/T2L+R3SH8/YxgQX9VCj1WTuTovgandEJFUfSn5/V 02WA== X-Gm-Message-State: AOAM530euFCi1QK8zK02WNpZXGTrQKr7qu3Pz6GnUoiE/v8Wg6pOhtDw r8i4q4PjHkISS8Q5MgcIGkekHA== X-Google-Smtp-Source: ABdhPJzdTnX6YRxAadr+Gz+9xp0mSGCkymfK4VLQjW7SPYXSCbH2S1IIuzR6f1HWLWNlUSX/q3NnaQ== X-Received: by 2002:a2e:8eda:: with SMTP id e26mr4944190ljl.266.1632401101517; Thu, 23 Sep 2021 05:45:01 -0700 (PDT) Received: from box.localdomain ([86.57.175.117]) by smtp.gmail.com with ESMTPSA id v18sm581717ljg.95.2021.09.23.05.45.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Sep 2021 05:45:00 -0700 (PDT) Received: by box.localdomain (Postfix, from userid 1000) id 02E7510306B; Thu, 23 Sep 2021 15:45:02 +0300 (+03) Date: Thu, 23 Sep 2021 15:45:02 +0300 From: "Kirill A. Shutemov" To: Matthew Wilcox Cc: Kent Overstreet , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Johannes Weiner , Linus Torvalds , Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , Mike Kravetz Subject: Re: Mapcount of subpages Message-ID: <20210923124502.nxfdaoiov4sysed4@box.shutemov.name> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=shutemov-name.20210112.gappssmtp.com header.s=20210112 header.b=C0MDMxtY; spf=none (imf11.hostedemail.com: domain of kirill@shutemov.name has no SPF policy when checking 209.85.167.50) smtp.mailfrom=kirill@shutemov.name; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AEB22F0000BD X-Stat-Signature: rnznncxdrj8y14aaqdnagk13jko6uprc X-HE-Tag: 1632401103-729707 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 Thu, Sep 23, 2021 at 12:40:14PM +0100, Matthew Wilcox wrote: > On Thu, Sep 23, 2021 at 01:15:16AM -0400, Kent Overstreet wrote: > > On Thu, Sep 23, 2021 at 04:23:12AM +0100, Matthew Wilcox wrote: > > > (compiling that list reminds me that we'll need to sort out mapcount > > > on subpages when it comes time to do this. ask me if you don't know > > > what i'm talking about here.) > > > > I am curious why we would ever need a mapcount for just part of a page, tell me > > more. > > I would say Kirill is the expert here. My understanding: > > We have three different approaches to allocating 2MB pages today; > anon THP, shmem THP and hugetlbfs. Hugetlbfs can only be mapped on a > 2MB boundary, so it has no special handling of mapcount [1]. Anon THP > always starts out as being mapped exclusively on a 2MB boundary, but > then it can be split by, eg, munmap(). If it is, then the mapcount in > the head page is distributed to the subpages. One more complication for anon THP is that it can be shared across fork() and one process may split it while other have it mapped with PMD. > Shmem THP is the tricky one. You might have a 2MB page in the page cache, > but then have processes which only ever map part of it. Or you might > have some processes mapping it with a 2MB entry and others mapping part > or all of it with 4kB entries. And then someone truncates the file to > midway through this page; we split it, and now we need to figure out what > the mapcount should be on each of the subpages. We handle this by using > ->mapcount on each subpage to record how many non-2MB mappings there are > of that specific page and using ->compound_mapcount to record how many 2MB > mappings there are of the entire 2MB page. Then, when we split, we just > need to distribute the compound_mapcount to each page to make it correct. > We also have the PageDoubleMap flag to tell us whether anybody has this > 2MB page mapped with 4kB entries, so we can skip all the summing of 4kB > mapcounts if nobody has done that. Possible future complication comes from 1G THP effort. With 1G THP we would have whole hierarchy of mapcounts: 1 PUD mapcount, 512 PMD mapcounts and 262144 PTE mapcounts. (That's one of the reasons I don't think 1G THP is viable.) Note that there are places where exact mapcount accounting is critical: try_to_unmap() may finish prematurely if we underestimate mapcount and overestimating mapcount may lead to superfluous CoW that breaks GUP. > > [1] Mike is looking to change this, but I'm not sure where he is with it. > -- Kirill A. Shutemov