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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 B8E55C433EF for ; Thu, 23 Sep 2021 23:49:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3529F611B0 for ; Thu, 23 Sep 2021 23:49:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3529F611B0 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7DBEE6B006C; Thu, 23 Sep 2021 19:49:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B1EA6B0071; Thu, 23 Sep 2021 19:49:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 652F7900002; Thu, 23 Sep 2021 19:49:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0142.hostedemail.com [216.40.44.142]) by kanga.kvack.org (Postfix) with ESMTP id 54B746B006C for ; Thu, 23 Sep 2021 19:49:02 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 11036180AD5C5 for ; Thu, 23 Sep 2021 23:49:02 +0000 (UTC) X-FDA: 78620481324.24.35C8BAB Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf02.hostedemail.com (Postfix) with ESMTP id B11317001A0A for ; Thu, 23 Sep 2021 23:49:01 +0000 (UTC) Received: by mail-qt1-f173.google.com with SMTP id d8so7884773qtd.5 for ; Thu, 23 Sep 2021 16:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=HAmJkHQDJJuagQxHQwV8veFd6rRsJ19PYDz/eTz1rB4=; b=K14UTK5w94Mq7Y7d0WepqQG3vE1pbUyxcPERyofOaaiyIVHxbYyK8CI3+1lVRKwB0g UGxogD+nvTWvrZQxq/FLDZ6pHz3qeBwZrqjFVAaElpacm1PBmVp4mepBXiWOr0KLSr0F 7JnWgQzbHfZJLJ6PjzcnIPJBq3MvzmnViyCCEKTVeT6dKhEXNkeosQ+TQYcWcrs+YvcJ 9vT+vOuW8zPALzddhzo4Ap+JWxJf42oQOtPTZSz1tqd4GHEfzK2J1n9TD2I/fu+4Ja8D 9FOg9+FIrgexLSYC7Hj+LAlJ74Zbhod48eyXJrVO5YIftatm4yzHbPA2//17GLe94VsH UOEg== 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:in-reply-to:message-id :references:mime-version; bh=HAmJkHQDJJuagQxHQwV8veFd6rRsJ19PYDz/eTz1rB4=; b=m0OGj/TeGxXjrmC+Sa6oiAcmNohat/0aqZvrZcG4Kv1piqZErXupi3g8r0V/ydz0U3 zPGq+y+yd+l04/MfHa2j6cF2ygQh/YonDmp5MsmC1YfgSkWJjw1ylmCJKEhDYhFQL5uv ySQtAacVRUXZsVtNkjvs7ALKiXtXTlad0sfTx6V6xqAgHsJilUCxiRJ5/BboFbUrGBjx elCge4AmVrt0Q2Q5bTyqA/e215UJsVt63Zhs2fvyKLTytdnZGOfFavXRTXLLtE7cB3yw MF4VMa/RzvpT1Zw1P76rWN3PU4wZdBNwUQiv5TcehRIJRVHTbS+4bFaTxbN3D6WSyLWx PvHg== X-Gm-Message-State: AOAM5328CCgMRVB/igfVVMxwVz6ABWp0t98OkNVD+wdG27XkZGjyzePD Snuo30fSF4BX/5dWoIuSQkngcQ== X-Google-Smtp-Source: ABdhPJyx4r0Ikvv2wOuAIuqSR2EMgA05qTmirNIFyEVLKHf+GXDLUUM3y7l0TeXUlNB2314011zgvQ== X-Received: by 2002:a05:622a:1792:: with SMTP id s18mr1465593qtk.136.1632440940819; Thu, 23 Sep 2021 16:49:00 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id q14sm5171666qkl.44.2021.09.23.16.48.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Sep 2021 16:48:58 -0700 (PDT) Date: Thu, 23 Sep 2021 16:48:41 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Zi Yan cc: Yang Shi , "Kirill A. Shutemov" , Hugh Dickins , 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 Subject: Re: Mapcount of subpages In-Reply-To: <2A311B26-8B33-458E-B2C1-8BA2CF3484AA@nvidia.com> Message-ID: <77b59314-5593-1a2e-293c-b66e8235ad@google.com> References: <20210923124502.nxfdaoiov4sysed4@box.shutemov.name> <72cc2691-5ebe-8b56-1fe8-eeb4eb4a4c74@google.com> <2A311B26-8B33-458E-B2C1-8BA2CF3484AA@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: B11317001A0A X-Stat-Signature: 9wyw4oicmz9wmxb551jkenar1xgz6rof Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=K14UTK5w; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of hughd@google.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=hughd@google.com X-HE-Tag: 1632440941-132934 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, 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. > > 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