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 486FEC2BD09 for ; Wed, 3 Jul 2024 09:21:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D3A6B6B0093; Wed, 3 Jul 2024 05:20:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CEB206B0096; Wed, 3 Jul 2024 05:20:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB2876B0098; Wed, 3 Jul 2024 05:20:59 -0400 (EDT) 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 9D26A6B0093 for ; Wed, 3 Jul 2024 05:20:59 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 219E8120A5F for ; Wed, 3 Jul 2024 09:20:59 +0000 (UTC) X-FDA: 82297897038.01.069C27E Received: from m15.mail.163.com (m15.mail.163.com [45.254.50.219]) by imf10.hostedemail.com (Postfix) with ESMTP id 90735C0016 for ; Wed, 3 Jul 2024 09:20:55 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b="hiJmdn5/"; spf=pass (imf10.hostedemail.com: domain of ranxiaokai627@163.com designates 45.254.50.219 as permitted sender) smtp.mailfrom=ranxiaokai627@163.com; dmarc=pass (policy=none) header.from=163.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719998444; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BTnssAx2cxCnOWayOPuWiQqj81ayGW11i7bWdYf4BJo=; b=LonAI52tUWI/VmAvc2vcQNucppN8FJlPMUTCMiRqqPVQ9yptQotZ41Pfzy/cia3YdaiSKi Qljlrg7FbJI2Aca3Z9LM1WH6sr8LSm1i2L9VoCHksFBY42I92w7Oc79WW+cU867FsrUdai KRYOzvn4FWqFGG7350Ll5OPbRSNOehM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b="hiJmdn5/"; spf=pass (imf10.hostedemail.com: domain of ranxiaokai627@163.com designates 45.254.50.219 as permitted sender) smtp.mailfrom=ranxiaokai627@163.com; dmarc=pass (policy=none) header.from=163.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719998444; a=rsa-sha256; cv=none; b=MOaqx5rkduQiSl8gjWlV5r5X6w/FKHx1tmBgRdQQJp02mYVmVpdaOL4q8loht33JQi96KO OPARDMgvEsvD5N1NgeupvkDksbu9I9TP57h4PDJbmqzMFBmlIYkBe7+o9pi22iXyZjvw6a hjpZcwH5dWuiFbfhiVVOv/Sre8yAaEk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version; bh=BTnss Ax2cxCnOWayOPuWiQqj81ayGW11i7bWdYf4BJo=; b=hiJmdn5/r1tETI0cFNGMu KP4M134fRLE3XF8DtHruRuzVy/vGGHGU9+fl/hNk9lCGVZc+0cb7s2kmVfYxOD5C e93prtr44x+v7DiHu7iO1yBtl8dMg6t6007MYg9ffXBDU8QHfCH4yHMSczAL7kXf 9gf2Zm1KBJdOCAUvdDiBqo= Received: from localhost.localdomain (unknown [193.203.214.57]) by gzga-smtp-mta-g0-0 (Coremail) with SMTP id _____wD3P3TXF4Vmr+vYBQ--.20081S4; Wed, 03 Jul 2024 17:20:25 +0800 (CST) From: ran xiaokai To: david@redhat.com Cc: akpm@linux-foundation.org, baohua@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterx@redhat.com, ran.xiaokai@zte.com.cn, ranxiaokai627@163.com, ryan.roberts@arm.com, svetly.todorov@memverge.com, vbabka@suse.cz, willy@infradead.org, ziy@nvidia.com Subject: Re: [PATCH 2/2] kpageflags: fix wrong KPF_THP on non-pmd-mappable compound pages Date: Wed, 3 Jul 2024 09:20:23 +0000 Message-Id: <20240703092023.76749-1-ranxiaokai627@163.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <1fddf73d-577f-4b4c-996a-818dd99eb489@redhat.com> References: <1fddf73d-577f-4b4c-996a-818dd99eb489@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3P3TXF4Vmr+vYBQ--.20081S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxAFyfAw17Xr15ZrWrXF48tFb_yoW5Cw15pF WYkFyqyr4DG3sYyr1Ivw1qyry8Gr98ZayUta43Cr17uF9xJF92qrW0y3s8A3W3Ar4rZ3ZF vFWUWF4qv3W5ZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0JUN189UUUUU= X-Originating-IP: [193.203.214.57] X-CM-SenderInfo: xudq5x5drntxqwsxqiywtou0bp/1tbiqRIMTGVOBJWk7QABsJ X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 90735C0016 X-Stat-Signature: d66zk8zxr4smyt4hxj3yarx98f6yu1p4 X-HE-Tag: 1719998455-136885 X-HE-Meta: U2FsdGVkX180SLT1pZvTDJNoKfXyaLcR5Vc3AxibheAzR0t/jEbHe2fT4Hs6NExTy2w2xbQF9xpt4zGvj062HDSJZLjEFbCKCmGvFrVRt1fmipbcB5KCunjzF9WlFxDTipD7amqKihfW96FrFHrkt4QMwoqKiJqNRn93fVApj3v4hdttM0WoOncPtpt1YUXEGbFxRsdEFyFKBcFxxI3XFh3YYRxreRRTXu6ZNs0aWOkS1XTMTu/jJmLOXkz2Wc6vQWn7U48dVN+L+WaVrdmXktk9qqGdqcBWm8OUQ7l/gJM+UuNiDMYHALAEtQWrVOiCqpqnp9N3J/e272MMu0FeNZIL2i8zLvWtpygrpRmjbvYJIamI//pUDNPSitMkoicDjLpVxjKjpUgtg5oqOuQTzcg+/iIK2oOt7S9bmKo/DO7wvVOQ8JgZjfWP3GQvuKYAI3Ip65lpitohG1t6tJCF4A2sM+cSk22eAXzv5aMgZqAsAZHGeREWXWQ1drLfsZFeK90kD+jFJa8QjnjWpVyrOpBYo9jQ6rsUFddMxqrHTRcHk9nsyEXJ8Fi0fUW1/3wW/akSG+DssfMX7kgs9Y/ioCRsK8FixQBZQgNO6rGo4Mm5o+c6cqBJhL+FXBmLcM0wqGzHIudImE/Q0uFzpIsC2loZXovQLjyEfE7qbkGAXLMFwPK3AAxAVS2OFU4D4vQ3m0CzZBtZVamgMP6QGUUcCWUYAQjUYkCsSceYw7ySkFmLwUQ6To6m1NSldvzeeXSj8Wk12SVAANoIGbWAoELvBAVp28X2zZtMQ/HKKFjp+DUVjkUSXc+99tBQzKchpXIkHddVtCRVIYipqyS/Pkn13Qdxp0v+fYeFa1nkfF8unroAHo+NyDeCK0vFFMwwXE5ekISm7urgaL7aH3zNGnRB5e7G00DHIAHIl+TA1jrNMNBNXYpZ7XarejtMZLkprV/3ygKsC8HalwEYIO+snh8 ZsRgbaAz lHWjpeSnTAmw8okjUGeyBCIlo2Ya3CV/jS+c7JpWQopKCR+fuXdOu71yoAJnNVhqPR4CoBhvcdGp4liCdPsCVvV4/fVau3E3HRahC7HHX3Y18+Wm+ttBzVhDfq0oT9k+IC3AjLZNUI5X/74+r6dWexK0dPoclNT2NbU27vBWgw9JVp6A4ndgMxjJVDnOVkIe8DxUv8brCKJAiVe1xoY1MFDFF+0qkqCwRNX8zdoTywo+CYg2/OhWrNJz/NG0HDArr/kMh+WsFem5fFKsSazNNmEJ6h6l0TF6nMXC5jBX3JZ1bk+/0rn8ZwFLg34tO2A6DssScRjVJWnFt15ZXUV9dJppXbscK6mpuulV57WTmWPRveh36N5gIr7fWcp7EQD+iGDxCbtKmj4GJUlkX+YZn66BaVeYTdwVSgYv/sHUlGlZY1gIXO4rbgJJ8IoDFc3wEVwpwGJK+wly9qiRMmnx5kbSM/A== 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.24 04:49, 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. Since commit 19eaf44954df > >"should only be set" -- who says that? :) > >The documentation only talks about "Contiguous pages which construct >transparent hugepages". Sure, when it was added there were only PMD ones. > > >> ("mm: thp: support allocation of anonymous multi-size THP"), >> multiple orders of folios can be allocated and mapped to userspace, >> so the folio_test_large() check is not sufficient here, >> replace it with folio_test_pmd_mappable() to fix this. >> > >A couple of points: > >1) If I am not daydreaming, ever since we supported non-PMD THP in the > pagecache (much longer than anon mTHP), we already indicate KPF_THP > for them here. So this is not anon specific? Or am I getting the > PG_lru check all wrong? > >2) Anon THP are disabled as default. If some custom tool cannot deal > with that "extension" we did with smaller THP, it shall be updated if > it really has to special-case PMD-mapped THP, before enabled by the > admin. > > >I think this interface does exactly what we want, as it is right now. >Unless there is *good* reason, we should keep it like that. > >So I suggest > >a) Extend the documentation to just state "THP of any size and any >mapping granularity" or sth like that. > >b) Maybe using folio_test_large_rmappable() instead of "(k & (1 << > PG_lru)) || is_anon", so even isolated-from-LRU THPs are indicated > properly. Hi, David, The "is_anon" check was introduced to also include page vector cache pages, but now large folios are added to lru list directly, bypassed the pagevec cache. So the is_anon check seems unnecessary here. As now pagecache also supports large folios, the is_anon check seems unsufficient here. Can i say that for userspace memory, folio_test_large_rmappable() == folio_test_large()? if that is true, except the "if ((k & (1 << PG_lru)) || is_anon)" check, we can also remove the folio_test_large() check, like this: else if (folio_test_large_rmappable(folio)) { u |= 1 << KPF_THP; else if (is_huge_zero_folio(folio)) { u |= 1 << KPF_ZERO_PAGE; u |= 1 << KPF_THP; } } else if (is_zero_pfn(page_to_pfn(page))) This will also include the isolated folios. >c) Whoever is interested in getting the folio size, use this flag along > with a scan for the KPF_COMPOUND_HEAD. > > >I'll note that, scanning documentation, PAGE_IS_HUGE currently only >applies to PMD *mapped* THP. It doesn't consider PTE-mapped THP at all >(including PMD-ones). Likely, documentation should be updated to state >"PMD-mapped THP or any hugetlb page". > >> Also kpageflags is not only for userspace memory but for all valid pfn >> pages,including slab pages or drivers used pages, so the PG_lru and >> is_anon check are unnecessary here. > >I'm completely confused about that statements. We do have KPF_OFFLINE, >KPF_PGTABLE, KPF_SLAB, ... I'm missing something important.