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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 0802EC433EF for ; Fri, 24 Sep 2021 01:11:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 93EF760E8B for ; Fri, 24 Sep 2021 01:11:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 93EF760E8B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 24EED6B006C; Thu, 23 Sep 2021 21:11:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1FE4A6B0071; Thu, 23 Sep 2021 21:11:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0ED9F900002; Thu, 23 Sep 2021 21:11:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id F3C936B006C for ; Thu, 23 Sep 2021 21:11:32 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AEA272BC2D for ; Fri, 24 Sep 2021 01:11:32 +0000 (UTC) X-FDA: 78620689224.40.8D295BD Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by imf26.hostedemail.com (Postfix) with ESMTP id 752AD20019C6 for ; Fri, 24 Sep 2021 01:11:32 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id ee50so29794757edb.13 for ; Thu, 23 Sep 2021 18:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VFfvy7CaZhgcLYY+FfLl/jy2UCxLFiyJXxO+xMizlY8=; b=QeEYSnEUK0ib55fvyXr+8QyGfTWVhNpZKIOFxKXARQsaOq+EjoYfzOvwxlMH8c430q JsH7ihjKKg1Lt+M0mVBnGgrHL5Md6WANoerWpABhN2bXSAQ+x8tp0lDd0UyE1H/nUKKT wAC9ybyfQ6mx/DeaZ2kND8MG5ba2syvCBYThPA9Ga7nI+dZps5WXsdr+QR0L3meTWoRd XE82tAF/HVIuzyx+qr7a90R9P9dwz1rde9+butcxcu/MSGwVs8HixMCTdvbdu0TJEmZR IerRQEyCfQBhfVbCpi5z5fdQ1YcEItDdGalGMI5WVaU01O7cKV3c3SV8Sw1oET9QkcPI MoVw== 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=VFfvy7CaZhgcLYY+FfLl/jy2UCxLFiyJXxO+xMizlY8=; b=PHG9hjkJwjN9ecT6l2r4fl8ygEveWWgf+1F3S51+vhMMNjxJT9LWSFBBTb8YOuzEd4 iCiN1ovp1DOjna/Eb7ui9Oe6XIane9bwY+3M2jlh2odMFzL6vSeNLNPia3PFAjvQ53Ze AthNYCFxg0oAfVnMYG9mm5+23+pB11qxuX+p9mhhD7HFP20scUSHTHXObXLfcyRsa++w fjK/lO//IS7LZOoqzKZsbMPv2LNM1a6tJYzvg9edVlkSv/jt0hVmLyjVPkljEE7l2KgL YkW2/88cCQju6DlnFxMiMNJq5ZjfIIhzZOVixp9282uM3jibBlAz/4Uo9IpXi72jA/2e 82VQ== X-Gm-Message-State: AOAM530CQKC3Ez7DSOfcStINbg7Nr+TqE0YC8Kp/TPrTYoSOdV2CO05o ofaq1Muo2MywQv9kWhkTdpW5SBYlvWJcybq+EFw= X-Google-Smtp-Source: ABdhPJxpnqVA1eKt+/Vve1DRMMUdEM9aoOdp0894puGK/ibv6YQaXIPIhLJUc2Jspr0c+7skoLATHzGi1V57jztpylE= X-Received: by 2002:a17:906:c7d0:: with SMTP id dc16mr8461596ejb.555.1632445891060; Thu, 23 Sep 2021 18:11:31 -0700 (PDT) MIME-Version: 1.0 References: <20210923124502.nxfdaoiov4sysed4@box.shutemov.name> <72cc2691-5ebe-8b56-1fe8-eeb4eb4a4c74@google.com> <2A311B26-8B33-458E-B2C1-8BA2CF3484AA@nvidia.com> <77b59314-5593-1a2e-293c-b66e8235ad@google.com> In-Reply-To: <77b59314-5593-1a2e-293c-b66e8235ad@google.com> From: Yang Shi Date: Thu, 23 Sep 2021 18:11:19 -0700 Message-ID: Subject: Re: Mapcount of subpages To: Hugh Dickins Cc: Zi Yan , "Kirill A. Shutemov" , Matthew Wilcox , Kent Overstreet , Linux FS-devel Mailing List , Linux Kernel Mailing List , Linux MM , Johannes Weiner , Linus Torvalds , Andrew Morton , "Darrick J. Wong" , Christoph Hellwig , David Howells , Mike Kravetz Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QeEYSnEU; spf=pass (imf26.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 752AD20019C6 X-Stat-Signature: ye8q6smfuuz4jtuh786zhcxnswgdogzu X-HE-Tag: 1632445892-197962 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 4:49 PM Hugh Dickins wrote: > > On Thu, 23 Sep 2021, Zi Yan wrote: > > On 23 Sep 2021, at 17:54, Yang Shi wrote: > > > On Thu, Sep 23, 2021 at 2:10 PM Hugh Dickins wrote: > > >> > > >> NR_FILE_MAPPED being used for /proc/meminfo's "Mapped:" and a couple > > >> of other such stats files, and for a reclaim heuristic in mm/vmscan.c. > > >> > > >> Allow ourselves more slack in NR_FILE_MAPPED accounting (either count > > >> each pte as if it mapped the whole THP, or don't count a THP's ptes > > >> at all - you opted for the latter in the "Mlocked:" accounting), > > >> and I suspect subpage _mapcount could be abandoned. > > > > > > AFAIK, partial THP unmap may need the _mapcount information of every > > > subpage otherwise the deferred split can't know what subpages could be > > > freed. > > I believe Yang Shi is right insofar as the decision on whether it's worth > queuing for deferred split is being done based on those subpage _mapcounts. > That is a use I had not considered, and I've given no thought to how > important or not it is. Anyway deferred split is anon THP specific. We don't have to worry about this for file THP. So your suggestion about just counting total mapcount seems feasible to me for file THP at least. > > > > > Could we just scan page tables of a THP during deferred split process > > instead? Deferred split is a slow path already, so maybe it can afford > > the extra work. > > But unless I misunderstand, actually carrying out the deferred split > already unmaps, uses migration entries, and remaps the remaining ptes: > needing no help from subpage _mapcounts to do those, and free the rest. > > Hugh