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 F18C0C433FE for ; Tue, 22 Nov 2022 09:33:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 421FF8E0001; Tue, 22 Nov 2022 04:33:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D1CD6B0073; Tue, 22 Nov 2022 04:33:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2725B8E0001; Tue, 22 Nov 2022 04:33:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 12AC86B0071 for ; Tue, 22 Nov 2022 04:33:33 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A0CE6A0D63 for ; Tue, 22 Nov 2022 09:33:32 +0000 (UTC) X-FDA: 80160565464.18.C9A45F5 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf06.hostedemail.com (Postfix) with ESMTP id 38B43180010 for ; Tue, 22 Nov 2022 09:33:32 +0000 (UTC) Received: by mail-qt1-f174.google.com with SMTP id h16so462300qtu.2 for ; Tue, 22 Nov 2022 01:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=m0GDJhfeb/mlDuXgY9TptD7saYe6PZinj6F8K2HKaeU=; b=Yh5afxIF4nlJ5tGvdSmhfMKs2zILGlBSVIL6Dq8svTLaZHbiVmfrTeSTd8e+VFVvst 3erxOjcuLZe1zhu4vW5V2FMYdoqnAyzGkmSS116EBggRl4QM2sJmFknFJXbXyQe/QgUI jartFLar8+ghwZmgy2UPOsDpCVGvHLnrwgpr8lTj2kDN/LztPZP9s4j5rs6eA62W3XCS XomsQLw4VX5GCBbdWgFTc2M88EcFeyEBemXHdHoGfHWJmV3whtY014IHkiRYExZSASq6 RSCpprBqiuPj8HU71hKDjHKiFHtYJZuydkXMf1qj4o//thj4EMkxAiA4/tBWhPv01ekX Unuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m0GDJhfeb/mlDuXgY9TptD7saYe6PZinj6F8K2HKaeU=; b=svSBS3XCKjOuXl8XaOWT0n26HzTHTfvmsiKQbhlMaJFX5IX/t7rZPmJIpHiYsnd2Qo 2sC9ofkoi9zZM3ltGjdxK+gSmDKhqpr91oxbG8eikPvTVHQdufLDWIRh+4q/06oAxxci UQeyshzYmItixRRN/V8iJPTeCqBICpmC8qBrt3bv4aRDXRzpL/8Ikjpw6njwKxUbwDGJ y3DpGhuvWsk9zhFHuc+mkNkcmhU2tqQC2u9qiue9g0YWLTYKFxgiDwj+FpUJr4IWI792 ObDj9Iw+bg2gvr5FW/9pwdpsNsUARSi37e5+wdXcPbwLm4UFKD2lbo5P2D+xRxxDvk1M LZpg== X-Gm-Message-State: ANoB5pkpOEPBUoJVBfyI6OoDSnZS6iJRAzfNzorS2AmPxm4J6nci/qeL 6Q6kfAilrjvYz0Bo8hjVhsiWfg== X-Google-Smtp-Source: AA0mqf54sB+Y5VKy2px/uKlEV8Zla8rGrgID1JcbJZtAIcoGIvncgsDgYkhDbtN2sgc7G9bAfT7YEw== X-Received: by 2002:a05:622a:4d94:b0:3a5:fb6c:d96a with SMTP id ff20-20020a05622a4d9400b003a5fb6cd96amr21306888qtb.185.1669109611343; Tue, 22 Nov 2022 01:33:31 -0800 (PST) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id t20-20020a05620a451400b006ceb933a9fesm10089200qkp.81.2022.11.22.01.33.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 01:33:30 -0800 (PST) Date: Tue, 22 Nov 2022 01:33:27 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: "Kirill A. Shutemov" cc: Hugh Dickins , Andrew Morton , Linus Torvalds , Johannes Weiner , Matthew Wilcox , David Hildenbrand , Vlastimil Babka , Peter Xu , Yang Shi , John Hubbard , Mike Kravetz , Sidhartha Kumar , Muchun Song , Miaohe Lin , Naoya Horiguchi , Mina Almasry , James Houghton , Zach O'Keefe , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/3] mm,thp,rmap: subpages_mapcount COMPOUND_MAPPED if PMD-mapped In-Reply-To: <20221121130900.xb224cesbzfptldo@box.shutemov.name> Message-ID: References: <5f52de70-975-e94f-f141-543765736181@google.com> <25a09a7a-81a9-e9c2-7567-c94ce18ac2@google.com> <20221121130900.xb224cesbzfptldo@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Yh5afxIF; spf=pass (imf06.hostedemail.com: domain of hughd@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669109612; a=rsa-sha256; cv=none; b=zTzfi/7OJd5wDDdUZM/OfuLLBdlR/xH2K7vkXCDMr6ghJLotKdmddvi25irq/1RVVKCo6Y TGAneo+GC/YVAeyvbIBDo2eofe0y6QJlgvcddRFg5TEv7DHWwklQR/LjTUtKXqhXtUQGdV rTnSb9hg6kl7Xj99sDjcoRMx/CSy5Ys= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669109612; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=m0GDJhfeb/mlDuXgY9TptD7saYe6PZinj6F8K2HKaeU=; b=AROYsjRimies6npaiaTnLuM4GCj9viQucPZDEE6Y1SvJsWoH/Ka/45ylivWj//8+cpxg0Q lPPi1p/ICSFbTBMknjyIV4gC+O9SoJZZQPO/vBEhIzds9JTIjCkj/v9AjunM8Pbs+4CaFZ hPbukn3dUh7K6y7oRszu0qEXZeQInAQ= X-Stat-Signature: ccgzt3immupzqrf7c7m569okccmgy499 X-Rspamd-Server: rspam08 X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Yh5afxIF; spf=pass (imf06.hostedemail.com: domain of hughd@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Queue-Id: 38B43180010 X-HE-Tag: 1669109612-910967 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 Mon, 21 Nov 2022, Kirill A. Shutemov wrote: > On Fri, Nov 18, 2022 at 01:14:17AM -0800, Hugh Dickins wrote: > > Can the lock_compound_mapcount() bit_spin_lock apparatus be removed now? > > Yes. Not by atomic64_t or cmpxchg games, those get difficult on 32-bit; > > but if we slightly abuse subpages_mapcount by additionally demanding that > > one bit be set there when the compound page is PMD-mapped, then a cascade > > of two atomic ops is able to maintain the stats without bit_spin_lock. > > Yay! New home for PageDoubleMap()! :P :) You only asked for one bit for PageDoubleMap, I've been greedier; so it's not surprising if it has worked out better now. ... > Jokes aside, looks neat. > > Acked-by: Kirill A. Shutemov Thanks; but I'm very glad that Linus expressed his dissatisfaction with the first implementation, this one does feel much better. > > As always few minor nits below. ... > > @@ -893,8 +902,12 @@ static inline int total_mapcount(struct page *page) > > > > static inline bool folio_large_is_mapped(struct folio *folio) > > { > > - return atomic_read(folio_mapcount_ptr(folio)) + > > - atomic_read(folio_subpages_mapcount_ptr(folio)) >= 0; > > + /* > > + * Reading folio_mapcount_ptr() below could be omitted if hugetlb > > + * participated in incrementing subpages_mapcount when compound mapped. > > + */ > > + return atomic_read(folio_mapcount_ptr(folio)) >= 0 || > > + atomic_read(folio_subpages_mapcount_ptr(folio)) > 0; > > Maybe check folio_subpages_mapcount_ptr() first? It would avoid > folio_mapcount_ptr() read for everything, but hugetlb. Okay: I'm not convinced, but don't mind switching those around: done. > > --- a/mm/debug.c > > +++ b/mm/debug.c > > @@ -97,7 +97,7 @@ static void __dump_page(struct page *page) > > pr_warn("head:%p order:%u compound_mapcount:%d subpages_mapcount:%d compound_pincount:%d\n", > > head, compound_order(head), > > head_compound_mapcount(head), > > - head_subpages_mapcount(head), > > + head_subpages_mapcount(head) & SUBPAGES_MAPPED, > > Looks like applying the SUBPAGES_MAPPED mask belong to the > head_subpages_mapcount() helper, not to the caller. Yes, that would be more consistent, helper function doing the massage. Done. __dump_page() then remains unchanged, but free_tail_pages_check() uses subpages_mapcount_ptr(head_page) to check the whole field is zero. v2 coming up - thanks. Hugh