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 B0C5AC27C4F for ; Wed, 26 Jun 2024 14:42:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CEBB6B0088; Wed, 26 Jun 2024 10:42:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27E876B0092; Wed, 26 Jun 2024 10:42:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 16D8B6B0098; Wed, 26 Jun 2024 10:42:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id EDE7F6B0092 for ; Wed, 26 Jun 2024 10:42:46 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6CC2FA3E2D for ; Wed, 26 Jun 2024 14:42:46 +0000 (UTC) X-FDA: 82273306332.17.0000161 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id 17B84180016 for ; Wed, 26 Jun 2024 14:42:43 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719412949; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SriMgVsweBBH32mzdVHcRLdED/iOpCKWtV+eGJdpD8Y=; b=1oKMmXVbziDZa6x3VmeGqFKl8Oa9SQycaq3t3MY8phXQ0rR97Ov33h4Ux0kdSivLS5qFyc 5LMtAyJjx3+wkxENpX4ZKmOVrXY6bOrNIdr2GDdq11QRNC4ALctF6IZQdu4IIzywGRNCoR cy6MdA1t3OthHjkOzUgb6yZzpOoz7rc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719412949; a=rsa-sha256; cv=none; b=eTo7iMsVTnD2yLCXc+A+3JZsLa7Vx+es9XMUwDKhlSAUWtMPGXaKj/J40hOTZCrEOKAdlO 0eOfbv4gJ+uFXT3XEYsCJxr+3dmFCaA0/1FG7zWWO8vMeHhYJJLZlMzTQ77gCj9Z85Sxmc MQe704n/S8ScnH2qcgwLINIJxL/msvQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D8217339; Wed, 26 Jun 2024 07:43:07 -0700 (PDT) Received: from [10.57.73.149] (unknown [10.57.73.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 767073F766; Wed, 26 Jun 2024 07:42:40 -0700 (PDT) Message-ID: Date: Wed, 26 Jun 2024 15:42:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] kpageflags: fix wrong KPF_THP on non-pmd-mappable compound pages Content-Language: en-GB To: Zi Yan , ran xiaokai , akpm@linux-foundation.org, willy@infradead.org Cc: vbabka@suse.cz, svetly.todorov@memverge.com, ran.xiaokai@zte.com.cn, baohua@kernel.org, peterx@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, David Hildenbrand , Baolin Wang , Kefeng Wang , Lance Yang , Barry Song <21cnbao@gmail.com> References: <20240626024924.1155558-1-ranxiaokai627@163.com> <20240626024924.1155558-3-ranxiaokai627@163.com> <1907a8c0-9860-4ca0-be59-bec0e772332b@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 17B84180016 X-Stat-Signature: d7g8r888rah8qka94x5umkxsdsp1snfz X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1719412963-863955 X-HE-Meta: U2FsdGVkX1/9mO4RnxDjXeYDQrG1U3GL+ApHt2n4MjrEL9lwN2yYdt9VWmA7MlFlSWtZhrtF6w2K2ArZS7yodj21ezCJaF0/4kmzYDaP1Dd53FGMWl1lX2hIvXFVuZXDnoqmEQsxtHAHVVNAm5n1FT3rj8GoWaoE7sstVdg4C9ibJDYw1Y7kDwOR65CdSXfvWJZPGtc1d95ruvXPyILVRoP/Yhe9THil1pr94nyEnhsgmCdhL4zaZ9IUCB1yp3M9HfeC1pi0w4WBBJYnR3DR6a8fr/P8R+MOtC3oucazo84EFdTg7OADnZ0Y0RzilS0+PMl5keVY8tgZH6r9w7c2sEFo7UfPnqhiU4PmuYW7JSL+NlpdWgsWlNQshncb9ZRwgf1LV5pzR73MuCE1KWThSycs4Xdo6fDASV0fo0HYxVrL0MwgXlWS2nDCTN0z7bPX6qvj/d19KhoclJnL1ekWDMofvS3EloQC9t5iJZdqd3G2/iPBkmL3oUL62qmowTz4+cDvNSGjg7BjlIvha3GWydILtZrWByto+UcWMrVqA8UPTap4TjnWSRkDGa5fKJ5hhCCYDf3dEmftqCcYcNV3gDp7zWcQKXqVNi6PmKynUfWhWVpZKYiGBEfuB8Yxh0gaLtUuR+MOTppU02RPJYvYGGfsjXc87cwV6EyagimFNxOFuhuiPAQZUpBXIk3Gn4ysqUX9MRAanL57LJy5McF4pIgO8WQUdvOR6reYL/JIii/IsNLv4W9Pmmyf/YyEGTw+W8TGJFf3TiFwaOQnXhoKxXWRd7pQXpo10jKX1f4ReK8o/NV+VbXUbmpsgYY4AOrY1SFaEMrHCzHtatqwW4W0cyL5qrRSRMPAVxVRj+hoSWW6AV8/DGvgf6njl64q4eeZVKdJ4aq+x51x/o3OXLgEGybPXPdF0ExfPqnk/XqwcgJsqLAMljlEl7UqKPcOPBRQyp4+TbSq2KS2/gvRlVg 6AwXAwPr mxWzBXdtU4QLmEg+cgv8/kefPSG2vd1P9CaGODMJfmB6aZqsGQKb/Y0UmiqlrIJg0tpFBlvRK86zDYrROkWHKJNR+QBXvkgaD34tZkGSdRz+1BhGdh+OoZAbHyZDZhIXfHVWD8exsTL+Ei3CHj69vzy1y9jCqRzcoA16K9Myhb47TBT52+6EGFGdAIi3VL4fGfH7fCAb0/6nwpuDU7NJ3HIqtCQYy3ok2p10AsLuPjQtcHB8nwrAqv+aYZwoiByjA4Do2 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: List-Subscribe: List-Unsubscribe: On 26/06/2024 15:40, Zi Yan wrote: > On Wed Jun 26, 2024 at 7:07 AM EDT, Ryan Roberts wrote: >> On 26/06/2024 04:06, Zi Yan wrote: >>> On Tue Jun 25, 2024 at 10:49 PM EDT, ran xiaokai wrote: >>>> From: Ran Xiaokai >>>> >>>> KPF_COMPOUND_HEAD and KPF_COMPOUND_TAIL are set on "common" compound >>>> pages, which means of any order, but KPF_THP should only be set >>>> when the folio is a 2M pmd mappable THP. >> >> Why should KPF_THP only be set on 2M THP? What problem does it cause as it is >> currently configured? >> >> I would argue that mTHP is still THP so should still have the flag. And since >> these smaller mTHP sizes are disabled by default, only mTHP-aware user space >> will be enabling them, so I'll naively state that it should not cause compat >> issues as is. >> >> Also, the script at tools/mm/thpmaps relies on KPF_THP being set for all mTHP >> sizes to function correctly. So that would need to be reworked if making this >> change. > > + more folks working on mTHP > > I agree that mTHP is still THP, but we might want different > stats/counters for it, since people might want to keep the old THP counters > consistent. See recent commits on adding mTHP counters: > ec33687c6749 ("mm: add per-order mTHP anon_fault_alloc and anon_fault_fallback > counters"), 1f97fd042f38 ("mm: shmem: add mTHP counters for anonymous shmem") > > and changes to make THP counter to only count PMD THP: > 835c3a25aa37 ("mm: huge_memory: add the missing folio_test_pmd_mappable() for > THP split statistics") > > In this case, I wonder if we want a new KPF_MTHP bit for mTHP and some > adjustment on tools/mm/thpmaps. That would work for me, assuming we have KPF bits to spare?