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 7415CC4332F for ; Thu, 10 Nov 2022 02:49:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4A8C6B0071; Wed, 9 Nov 2022 21:49:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFAAE6B0072; Wed, 9 Nov 2022 21:49:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE9B86B0074; Wed, 9 Nov 2022 21:49:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C1D586B0071 for ; Wed, 9 Nov 2022 21:49:33 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9376BC05F8 for ; Thu, 10 Nov 2022 02:49:33 +0000 (UTC) X-FDA: 80116001826.14.FEFDA1A Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by imf20.hostedemail.com (Postfix) with ESMTP id 3B4861C0004 for ; Thu, 10 Nov 2022 02:49:33 +0000 (UTC) Received: by mail-qk1-f169.google.com with SMTP id x18so432320qki.4 for ; Wed, 09 Nov 2022 18:49:32 -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=6TexcarRbXmqxk9wL/ILQGc5M5ZNt/RsOVA+Ap3ji0g=; b=RSnomFS+DpxFQ06pn86pqBbEYB/57ZUBxzIpuydZoXglzD5HpP3WFKoAo55bDZFkV/ 7sKsp3at97zghtT7UozO7c2F2lPnSuGPgXU/Iy6AHVTMNYr+IKkshzzK81p5+zJ1z+zI Vu1u0/CuV763qShcU1xpOasxEaGKn7sjbn6JjPDCM367Eu9SH/Eeb/sfGr58z6LlhmbC 9q+6m0y3FEUSM0vtlMDW2ixCYuJu6RlkrMUpbbXJC8xmHJYwFEfGIOXfcklPN2Cmpnln CF8gy/JjUgWsfoiDcnfoEWnvMZYOAjHDmbVaezszHY8wwKDyFmJkq3iahqbami6YT1VA 1AYA== 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=6TexcarRbXmqxk9wL/ILQGc5M5ZNt/RsOVA+Ap3ji0g=; b=QPXuCcj8E0iVC8fTxEprsCuvMJMZFOswdol5oGcBaEmTe9Go5+h5STM6hjEw2nVpUH yKHgj+zVnZUMA6M39+JSgnXY7L78EBhp8uyeQvqC//DGp4FuySHIO1qUNBooLHQhfi4x gL++miGZ577t7ca9Jn/k5TlBGPtPkKf9aoOIIPn+dHvDDFfUXAX4vwBuwVRPh8Z4KiF1 mlwl9Qfcp/h6y62tg8Mapa7ol1z+RDijlf94RFuCOCwO1v0qy8S4sOGQyNxJJqxvYLpT bONUQkOmt+h9gEVRtqxe+z7MRaGdz/tXaIUOYqDvc4hiSfo8gRGKXZmJibohIc9QuNMl eNcg== X-Gm-Message-State: ANoB5plajtIbfF5DS2NsBUZ91CZCmL9EkVoL1T9nJ2eI1buSyjJuaHnz X67u0+yRdXhnk9Qk9DPavnZTlA== X-Google-Smtp-Source: AA0mqf5FmcgaLL3XZUshwPdzBGYydVkpziELkDAGxVKJRzGZg+afKWMa0WH0YqlRUzMlyR5uj1wGmQ== X-Received: by 2002:a37:de17:0:b0:6fa:d987:a574 with SMTP id h23-20020a37de17000000b006fad987a574mr13720155qkj.329.1668048572349; Wed, 09 Nov 2022 18:49:32 -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 h3-20020a05620a244300b006fa4cac54a4sm11271564qkn.133.2022.11.09.18.49.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Nov 2022 18:49:31 -0800 (PST) Date: Wed, 9 Nov 2022 18:49:29 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: "Kirill A. Shutemov" cc: Hugh Dickins , Andrew Morton , 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: simplify compound page mapcount handling In-Reply-To: <20221105195115.2d5yvvepdjsqjmmv@box> Message-ID: <7f9e1dfb-64f7-62a1-f35-988825303814@google.com> References: <5f52de70-975-e94f-f141-543765736181@google.com> <47ad693-717-79c8-e1ba-46c3a6602e48@google.com> <20221105195115.2d5yvvepdjsqjmmv@box> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668048573; a=rsa-sha256; cv=none; b=Af7qiFcXNR7jk9uoIebbj1vGxaK2s9Fyl2nJFtUH3UF/SWuLOz1zSug1HeWuz1Rjc00yZx HS5ZhPtVynJC6JMGrR4CxR4L0d6bgSE4O80WjkMQlJWgaxCDfKu9I8BM1vVIGkg1MLGGBr hmfEtd/9n0oGEHhJsEDaRduIBhfFQSw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RSnomFS+; spf=pass (imf20.hostedemail.com: domain of hughd@google.com designates 209.85.222.169 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668048573; 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=6TexcarRbXmqxk9wL/ILQGc5M5ZNt/RsOVA+Ap3ji0g=; b=BIQaZulHuuBlCjL3McNyFHv2qAGWBgd7y/V6SBWr2dz1P6DJ9hP6mwTPBEzFlWX3crXDpQ bKMe1BrpCBQtkBPq1wpRqjYWwcsEaKKubfuesx19morbuT3mNHPQuDdx09Fe25SZb5DQbH ptgUso5ufTXGPKq/36TizK0cNsWuNE0= X-Stat-Signature: hbxc7jm35majjbamww5nqnkiu1kig534 X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=RSnomFS+; spf=pass (imf20.hostedemail.com: domain of hughd@google.com designates 209.85.222.169 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Queue-Id: 3B4861C0004 X-Rspamd-Server: rspam09 X-HE-Tag: 1668048573-498127 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 Sat, 5 Nov 2022, Kirill A. Shutemov wrote: > On Wed, Nov 02, 2022 at 06:51:38PM -0700, Hugh Dickins wrote: > > Thanks for doing this! > > Acked-by: Kirill A. Shutemov Thanks! > > And sorry again for PageDoubleMap() :/ It did serve a real purpose, but I always found it hard to live with, and I'm glad that you're happy it's gone too :) > > Minor nitpick and a question below. > > > @@ -829,12 +829,20 @@ static inline int folio_entire_mapcount(struct folio *folio) > > > > /* > > * Mapcount of compound page as a whole, does not include mapped sub-pages. > > - * > > - * Must be called only for compound pages. > > + * Must be called only on head of compound page. > > */ > > -static inline int compound_mapcount(struct page *page) > > +static inline int head_compound_mapcount(struct page *head) > > { > > - return folio_entire_mapcount(page_folio(page)); > > + return atomic_read(compound_mapcount_ptr(head)) + 1; > > +} > > + > > +/* > > + * Sum of mapcounts of sub-pages, does not include compound mapcount. > > + * Must be called only on head of compound page. > > + */ > > +static inline int head_subpages_mapcount(struct page *head) > > +{ > > + return atomic_read(subpages_mapcount_ptr(head)); > > } > > > > /* > > Any particular reason these two do not take struct folio as an input? > It would guarantee that it is non-tail page. It will not guarantee > large-folio, but it is something. The actual reason is that I first did this work in a pre-folio tree; and even now I am much more at ease with compound pages than folios. But when I looked to see if I ought to change them, found that the only uses are below in this header file, or in __dump_page() or in free_tail_pages_check() - low-level functions, page-oriented and obviously on head. So I wasn't tempted to change them at all. > > > @@ -1265,8 +1288,6 @@ void page_add_new_anon_rmap(struct page *page, > > VM_BUG_ON_PAGE(!PageTransHuge(page), page); > > /* increment count (starts at -1) */ > > atomic_set(compound_mapcount_ptr(page), 0); > > - atomic_set(compound_pincount_ptr(page), 0); > > - > > It has to be initialized to 0 on allocation, right? That's right. I was going to say that I'd commented on this in the commit message, but no, it looks like I only commented on the instance in hugepage_add_new_new_anon_rmap() (and added the "increment" comment line from here to there). I visited both those functions to add a matching subpages_mapcount initialization; then realized that the pincount addition had missed the point, initialization to 0 has already been done, and the compound_mapcount line is about incrementing from -1 to 0, not about initializing. There are similar places in mm/hugetlb.c, where I did add the subpages_mapcount initialization to the compound_pincount and compound_mapcount initializations: that's because I'm on shaky ground with hugetlb page lifecycle, and not so sure of their status there. Hugh