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 720E3C2BD09 for ; Thu, 27 Jun 2024 09:17:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C6E306B0082; Thu, 27 Jun 2024 05:17:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C1D1B6B0083; Thu, 27 Jun 2024 05:17:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ABD386B0088; Thu, 27 Jun 2024 05:17:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8E15E6B0082 for ; Thu, 27 Jun 2024 05:17:02 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id F357881C9C for ; Thu, 27 Jun 2024 09:17:01 +0000 (UTC) X-FDA: 82276114242.14.B57FB4C Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by imf03.hostedemail.com (Postfix) with ESMTP id 2F8E620014 for ; Thu, 27 Jun 2024 09:17:00 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XMV+O1U5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719479807; a=rsa-sha256; cv=none; b=RBYQu+tzySkZ3K0a+LWpZoJS4hfe9FWieRXBX5KAENjC0iW8lLQf+1Aq03MbksnStcRQWX f+sxUE3spojP5ou4KGYIDE3BnJxcv0Lfx9N9ynEpM18viaen0Qtv9K6wLoI65UA9rLP/NN QMRSUeEQzgOjta9UeKh6cULwbVje3yU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XMV+O1U5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719479807; 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:dkim-signature; bh=laUAmHHeAWLZesmoRpJPc1jRFT5y8CgDrTpEQBOLTsA=; b=ImqpXum0FKrtV75DOTqD1dV9B0e1+CeoCBnp+AM6i4sVRlNXE+affixIuTX9oYhqoJr3bV X4LmPV8UaZVp6ZbxtCdbN9QJ02cO+1WQrwqjA2lOtXoivXSXafCzgMMNA+1Cj7P/g13pDT c4Jcrix2DwEuh4EN1CSmyDvfcv+3LRw= Received: by mail-ua1-f45.google.com with SMTP id a1e0cc1a2514c-80fbfeecca1so598055241.1 for ; Thu, 27 Jun 2024 02:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719479819; x=1720084619; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=laUAmHHeAWLZesmoRpJPc1jRFT5y8CgDrTpEQBOLTsA=; b=XMV+O1U5Cvq/z5+dv2hA4P4iT/UYaKk79QEmRQzFunAzIv7KRtQcJqeSMEEdSC6b+a Lj+nZ9ciSnFfBh0Tq8WB6vCOc12eKnNl346Bk2vx7FGBcHOJtXiEjOjWXMzD3rIcjauW INaRJDuSIhdmrdZNRq8yO/ev34ieDZIMke7jShGcEctN0BIaOVvMIQhHjE+Gcrl6ko8w G2u2fbC3mWb/RwTxD1K08iGmsP10cahElpYVKYhiL/X3QuWvrOEqrZRqLhFIyEAJra7s yruuZ8zv0yAje5uCkeNk6ID46/wGoP0ISfFSMDxvglmFqrxO6VUZXCTHRZG902AFHOq+ cooQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719479819; x=1720084619; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=laUAmHHeAWLZesmoRpJPc1jRFT5y8CgDrTpEQBOLTsA=; b=TmdK30d7yezGSxxb0ses4mwUZ+/kxv0V53czfhfFF74m3JSx4SbZShYoU239C6adMn a7XpOZ5+bLxJC1RkrbE4RZq57ZJmIOEuUPmkEgIQrjWndG44iE1z5mO+qmbjyH4Hp1N2 dSSPf2m60xPVnLLHTSl3AFIuc86KOkz+Fa+hjblv45gjpunLV9f0D3DtIQkd3+IKizez +JBDPRiLML7RI21v2216Qp+HiePljANz8HmvOp71qBCtw6QjpKKIKF8eY4ICmDcc1Y0x Sumh2dsxelPH4tdZLlJsQ6H0Ge2dohL38gQIFCbF4wRfkVu0tjHouExZmI3U89H0qVcA Af/g== X-Forwarded-Encrypted: i=1; AJvYcCXQxjp2Z7tcyAZ81lW+rmVM00lNmlqwt2k5jaz83lBKDjfQ16Eidkk2aKTE9R265VtaUnc5NoCoij2hrWiRWIl9euE= X-Gm-Message-State: AOJu0Yy39vhfYQmM8axpj0jQPkMs9G/RXJY+2iv9RmLCV5b3lzCW5Nsx KJJIgEy2t805MiX9Njg73QBfuRNy/m0BbA+mqko5++6q719AwAXREdhlCWxpopgo9BwcHhYWLcp sLcb3OYXCQ6r4T67EhzTGXnfRcaU= X-Google-Smtp-Source: AGHT+IGDLHfABvb02LaUhvggwzZRRRzaS6X1WS7h/Jy/1gtYvCD5PesYN8abGcl17/Mxznh8eEfXyqeLXliAPtLH/WE= X-Received: by 2002:a67:b449:0:b0:48f:454b:f4d3 with SMTP id ada2fe7eead31-48f4ee77999mr11567186137.2.1719479818969; Thu, 27 Jun 2024 02:16:58 -0700 (PDT) MIME-Version: 1.0 References: <20240626024924.1155558-1-ranxiaokai627@163.com> <20240626024924.1155558-3-ranxiaokai627@163.com> <1907a8c0-9860-4ca0-be59-bec0e772332b@arm.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Thu, 27 Jun 2024 21:16:46 +1200 Message-ID: Subject: Re: [PATCH 2/2] kpageflags: fix wrong KPF_THP on non-pmd-mappable compound pages To: Ryan Roberts Cc: Zi Yan , ran xiaokai , akpm@linux-foundation.org, willy@infradead.org, vbabka@suse.cz, svetly.todorov@memverge.com, ran.xiaokai@zte.com.cn, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2F8E620014 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: r7beh6hopnbsqd1ykqdxunxhs76s4rj4 X-HE-Tag: 1719479820-255854 X-HE-Meta: U2FsdGVkX19T/fFtYEifXfSLMHiyKQRh08YWwejKX9kQd6CF9/Dgr+2vKq1IAgdR4qlN/MGjVFVDMXp4RjmdP9VH65fsm2F7IlLeMFCNh8xmaZZD0pQVycjO0vxpFJgP2/87qLgy5xanQqhBy0a12rxgJbfjIvI7AhbyBkgVZFaKKSCBp+CQp9PWxmKEqa5YRIjMDQfcEN0KWcKTqTxRWNiwJ7UZlQUHvYl6dhVaXqH3HuGj2B7uQyFgPOB0tSz8tlGmQS6FYAK2mVaMY2rrpdSq8LyB5mWE3Zw/44xK/b2QiLffIXDUsXRN7e5cv0h6amjhDpE+/rBRn3mls6sPnvYeZoyYyhnJ8d5lx2MfCbGS++RyGHIfXwEPJJHktq4BW4TeB1I7Q8ofT69B92jb31AKUqs3yPi4ASm3iTZyjXL3/ItjABRWhJSgm0bbjg8Nr/2KphCVa4LEL6hQ1uo0XyXeBPpI8SuT+tvvzc/6nwXpAs0BT+ZsEBhWnEnpy/v4RaS4MEzAI2jkNrFXSrxSbL7hCihAvjEs1s115T1AppZSM+wrlRCsjIh4uAaWCUFMsxQvBnmlbiUZ91uZUA/EqbZ9Kx+e3cXtz+/JEGZ7oE8hY9LoJJzkqBnS8a/gJ0F9nnL7//depiZsjdO034czD9uNwxuk1iwi8L07Dnm6dRLQZi5PAAOvqemJIetuDL7r0fN0irLrlGPE8Pruk8dkYgYhz0u1YzIxqfsBJ24wWsaGc8pahaTRFtwjY5m+dE/JCLEQwKNh+aX76uuXXppEejrQP9PS5pTIMbe5OAqlF7QSToKmWfuOFdeBXBatudLqlYgiXI/ZhUmNn2bxaIDzuxRksqYlG9UI7ER45UxFMsutm5jiqA4Z/iM2t5BUEu9Ei7IBLfoouZOVQBQiTv2mizrbh1jT3k3Mb087uAMXjPmxwy6OMTfgl8lr124B5iOXqsgPaUtx/PuWt3iYVMP Ci9MfXbq P09ML0EAC6xs0adjjN/B6dn8HKUZYF0e8w0AlBVUZjXP2F0TAmoN6QJt6UyOFiqCUpqANKaB6DbGUefXm4JidNjTpUH6apy0Xq5kNl9GKTPt0KpYm7OQtrt0cP5qYyJ6AWvI93W7OGpVX9NW7vlpMnUavAIfCe+MmnTpTQZXTib+YZOssailGsDXxBs0AF2D1mFG4HfTDwuFXKz6z++PHG381Z8k0VEuNS28bRHfBXwhPjxN6WnrRUcPNliLRGsKWqEYjvXDSgAuRrNIvdqfSVpSfoOxjFUw9FcRLbv/4GGcwqOfEAAsneS1r9MYTn83FM585JNah6puN50FMgPkL1ZAoQ7WDR3aYyLQsIM9WuOHYpzqYPjiCS8QkTaa7w8wBkk9Dqanx0T5h0xJs2bHUS7zI3OlMu0OGddMMNyyDl0A9KIkXJiaSyT3ivO1YLDK5anjeptFPN67f+o0EkD0nf9AmJT1wpOZrV7NiW+FZP3Koq5I= 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 Thu, Jun 27, 2024 at 8:39=E2=80=AFPM Ryan Roberts = wrote: > > On 27/06/2024 05:10, Barry Song wrote: > > On Thu, Jun 27, 2024 at 2:40=E2=80=AFAM 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" compoun= d > >>>>> 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. A= nd since > >>> these smaller mTHP sizes are disabled by default, only mTHP-aware use= r 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 mak= ing 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 cou= nters > >> 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_mappabl= e() 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. > > > > It seems we have to do this though I think keeping KPF_THP and adding a > > separate bit like KPF_PMD_MAPPED makes more sense. but those tools > > relying on KPF_THP need to realize this and check the new bit , which i= s > > not done now. > > whether the mTHP's name is mTHP or THP will make no difference for > > this case:-) > > I don't quite follow your logic for that last part; If there are 2 separa= te > bits; KPF_THP and KPF_MTHP, and KPF_THP is only set for PMD-sized THP, th= at > would be a safe/compatible approach, right? Where as your suggestion requ= ires > changes to existing tools to work. Right, my point is that mTHP and THP are both types of THP. The only differ= ence is whether they are PMD-mapped or PTE-mapped. Adding a bit to describe how the page is mapped would more accurately reflect reality. However, this cha= nge would disrupt tools that assume KPF_THP always means PMD-mapped THP. Therefore, we would still need separate bits for THP and mTHP in this case. I saw Willy complain about mTHP being called "mTHP," but in this case, call= ing it "mTHP" or just "THP" doesn't change anything if old tools continue to as= sume that KPF_THP means PMD-mapped THP. > > Thinking about this a bit more, I wonder if PKF_MTHP is the right name fo= r a new > flag; We don't currently expose the term "mTHP" to user space. I can't th= ink of > a better name though. Yes. If "compatibility" is a requirement, we cannot disregard it. > I'd still like to understand what is actually broken that this change is = fixing. > Is the concern that a user could see KPF_THP and advance forward by > "/sys/kernel/mm/transparent_hugepage/hpage_pmd_size / getpagesize()" entr= ies? > Maybe we need an example which is thinking that KPF_THP is PMD-mapped. > > > >> > >> > >> -- > >> Best Regards, > >> Yan, Zi > >> > > Thanks Barry