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 5C2D9C433F5 for ; Fri, 24 Sep 2021 00:57:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C58C460F70 for ; Fri, 24 Sep 2021 00:57:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C58C460F70 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 0D854900002; Thu, 23 Sep 2021 20:57:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 060886B0071; Thu, 23 Sep 2021 20:57:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6AF4900002; Thu, 23 Sep 2021 20:57:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0036.hostedemail.com [216.40.44.36]) by kanga.kvack.org (Postfix) with ESMTP id D52216B006C for ; Thu, 23 Sep 2021 20:57:26 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 7FBCC18379546 for ; Fri, 24 Sep 2021 00:57:26 +0000 (UTC) X-FDA: 78620653692.11.607A04D Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf14.hostedemail.com (Postfix) with ESMTP id 43A6E6001989 for ; Fri, 24 Sep 2021 00:57:26 +0000 (UTC) Received: by mail-qt1-f169.google.com with SMTP id x9so8120104qtv.0 for ; Thu, 23 Sep 2021 17:57:26 -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=yOg+nzwKS/Xe9boE1XYCVEvuo4RAHMroRl1PMQiLGaE=; b=UdSi8cTqG77oru82hEmJklps5D805r9qSr9pTi5SYcSwhasEbm9rWVspjcCQSnRf8Q oX8CtlqZO7VNdTkw/JeNVrL4ZAJDGwNEL54yb43mYHbxLf94ZzRljWHYkVJj6/LZUIw4 6ZAG6NTAVbHoPcQCdj2m5GcMHAt1TNFWi3i7J0CDS9W39XJDpK3YH7T2NXD7OvWggs8T ofMDlCmiLCJT7MWrlO0+jgNkRRgpFqZC5t5cbYoiHrx38fpoY25TgBNELp+8xoLOUpYU DzRGKPLbppIUwv3bQZGzMtW+dY4LJxp/H4wNNf7gQFX4cHFxnEH4RP/74F4affCg0oyy rEUA== 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=yOg+nzwKS/Xe9boE1XYCVEvuo4RAHMroRl1PMQiLGaE=; b=yKqMSV7MSSaeKLLGONTOchV/ajygcGKZ1y1qaDEMUk0dv5hS7FzGCGfbKXm4zTPc// +0njOgq0CHO1XEzqMOQbPxj+yjBnHddLZr0DGd2civB1ztdv5M1wKTH2bYFo3Q4pMKpU 3OsNwMEfCFjhbqchwbu3Td1DvR/5Miu2sCJZ+e7BUpAo+r0aIr5BxNTawqujLtcABEKo ldIvoMMu6fRxYsYDiRKLkCRUyn6ADq6nW6j8i6u8CXro1AV0DM+oSYu+RK/nuWQ4P+cm qcbKsxBMFEaPgLXWfV9TVCcVA9cOI3Og7ClULOWkITeDxMqHroYGMt8MTYpNj1n0hOq8 1rvQ== X-Gm-Message-State: AOAM532Vz1Qayudv3SIlB/q6BtrodEmQEoFm2wAJHZF/eL4ks06qHBP0 W5Oe5LFPx6f3QzlAYeuhYxJt5g== X-Google-Smtp-Source: ABdhPJxKZbP06lKD6aeiNcFdgQv2031ZYnZqb+thvCaZxx9HD9ZRTfzF1jKNdAdawTbHh2lJoH/5Hw== X-Received: by 2002:ac8:4755:: with SMTP id k21mr1730713qtp.150.1632445045392; Thu, 23 Sep 2021 17:57:25 -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 g22sm5530005qkk.87.2021.09.23.17.57.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Sep 2021 17:57:24 -0700 (PDT) Date: Thu, 23 Sep 2021 17:57:11 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Zi Yan cc: Hugh Dickins , Yang Shi , "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 Subject: Re: Mapcount of subpages In-Reply-To: <24B432CB-5CBB-4309-A9D0-6E1C4395A013@nvidia.com> Message-ID: <63e1cfcc-b7dd-ca55-39b2-7a9d2f6ff7eb@google.com> 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> <24B432CB-5CBB-4309-A9D0-6E1C4395A013@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 43A6E6001989 X-Stat-Signature: 8oa4us364zkk9z7gpqa57j1rdspm18pg Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UdSi8cTq; spf=pass (imf14.hostedemail.com: domain of hughd@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam06 X-HE-Tag: 1632445046-366714 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 19:48, 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. > > > >> > >> 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. > > You are right. unmap_page() during THP split is scanning the page tables > already. > > For deciding whether to queue a THP for deferred split, we probably can > keep PageDoubleMap bit to indicate if any subpage is PTE mapped. Maybe, maybe not. > > But without subpage _mapcount, detecting extra pins to a THP before split > might be not as easy as with it. This means every THP split will need to > perform unmap_page(), then check the remaining page_count to see if > THP split is possible. That would also introduce extra system-wide overheads > from unmapping pages. Am I missing anything? I did not explain clearly enough: a subpage's ptes must still be counted in total_mapcount(); but I'm suggesting that perhaps they can be counted all together (either in the head page's _mapcount, or in a separate field if that works better), instead of being distributed amongst the separate subpages' _mapcounts. And this would lower the system-wide overheads inside total_mapcount() and page_mapped() (and maybe others). Hugh