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 23D07C3ABC0 for ; Thu, 8 May 2025 13:12:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DB8FB6B008C; Thu, 8 May 2025 09:12:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D67AD6B0092; Thu, 8 May 2025 09:12:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C08ED6B0093; Thu, 8 May 2025 09:12:17 -0400 (EDT) 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 9F4F36B008C for ; Thu, 8 May 2025 09:12:17 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2B2A6C021D for ; Thu, 8 May 2025 13:12:19 +0000 (UTC) X-FDA: 83419779198.07.930B4D7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id BD4054000E for ; Thu, 8 May 2025 13:12:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="f8/Vipcb"; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746709937; 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=ZXNsBRZPu/xThTTrtIQSnufM6LFKDcO3TPDgoFJD0O8=; b=bndzUGD/juSBg4yyOfitcYmXOb2Y1bVTpfpSAqZOt/QUX1um9mL1WLDJhn8l3Hw/GaGefO VlmyQZwG1V8Cr0PeyrIZrrky8cE4Hqi4kEFpfMFosoZi1lFf5mqK01AlBif1V1jK1THPp2 LeqvFdKss10mgN8SWkEM7qB6PUkzuOg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746709937; a=rsa-sha256; cv=none; b=ntzdKALIclOR4j96TxDsTVFKxqwYNt0DnVCeyEcqCTtDJIsYsdsgFlA/AAfXe5vSUoeBH9 QENjgavqvuF9o/F9cds6LLQz5dSNnQhpm9Y7NyFzg6JE63WN9Z3yVpny92y9bN07zEhtyJ iyymVTqskAefzFbT7S5Rpt40UY21/BM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="f8/Vipcb"; dmarc=none; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ZXNsBRZPu/xThTTrtIQSnufM6LFKDcO3TPDgoFJD0O8=; b=f8/VipcbnCd6DUJ7G2u+1+evQ6 tQAEs2eTQnY+3RjRue9M+asIHx2EvX5Iq20eVyg3pGQfZn4er1oXTzQ7opuF22aqViLxFE3ox/Dlx gb5TTGccy0XYs3eVl089/nnLcs0M/vV6jcELp8913KkdWhIkc06w00LEvOdH5oKD8fqJ//1697R6i NZdHAGSixjRc+ANNU9U/mSmVIPVuPeV+aZJPMtq6MIF3ecTK6POw4wdYxN+CAiPZ3IeK8O6F1tuI3 FQFd+02oeFdfZjBgAClIW8VJ29oBTn8G/gQWHNndJAYqZlmrCJh/dxxrpxCNKcpICuCOwhzTc0AEO 8YYAHr/w==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uD12i-00000000Xj7-12ac; Thu, 08 May 2025 13:12:04 +0000 Date: Thu, 8 May 2025 14:12:04 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Zi Yan , Baolin Wang , akpm@linux-foundation.org, hannes@cmpxchg.org, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] mm: convert do_set_pmd() to take a folio Message-ID: References: <8e33c8a65b46170dfd8ba6715d2115856a55b8f6.1746609191.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: BD4054000E X-Rspam-User: X-Stat-Signature: 41q81ohuwco7qdf1ukpg5nh3xbmasigs X-HE-Tag: 1746709935-946400 X-HE-Meta: U2FsdGVkX1/LFqLLe6UoBOxCKt2+1+jsr/T7iaZNkyiDBJHM/TyYKfrW86E80iu1KpyFlYe3/I1dRXuUIozqAwQdzdmrnhCQSrd0GYi3ocJc4BuddbfbAcOhuHia9TmMHaQ0q5hyKysxe9TjmGZZN3NFgVuDMVwBmgV8NiB8/tnrYo8x7lcOKOfg2PNk3ax8mq7qWSJjVae7jPaURvVv0vima2otg0MNgMD6dlCmLZrtg1zNRo2kl6kXpmXApMYEoqMerCQsR2gJz3+zQ7LFMwob6dwsPrU5KYxXfmLwlHWzJi5bdJdcO8UoG1kuamLj4m3GGG/rZvhpz73OLZwma5iyykdhB1vmAqf4a/pa2/N7TpTcef9+AmlFxt5S5e4ajXS27W2xOscB2L3SyBFMf1HdstjeJq7edsWi2O86TDrPigqOvvJZCz74SieyqkLfqWHUrOsPvwHceJJuwVXsK4YGFeVO86O6hwAF7Q6b9hG+TpbiHn6zD3HtZe7gtZx1l7EE1XFvkyZWppuqdjXxdx93OY+jdscn3nPSUMMS0oVKAuxz2UgIUonXZEzKy63VdOyzojhKcQMk4sbgHaVKFyKg2S+oBeabLOMrM7Qy8fcwqFTeXkQhrK+cxnZKKa5RXHE4IYvPQgP6Qr+IYCPFzrZaMvFvV3dhc0QVXmKidRGio6h1b+KmgncpWRmIIMCtdLsjYBJgdgj8x5weNlOh31aEDY60f09ZgxfPp6S4OAUglQ2LsMbF6ZU8J7vDflI+6T+iCQp83iJ61lu6TUBgpDYA1/4atbZBl3lVGytknns6a+Sp8RdbR9Xk66G6DPKqTBt4Kd4maJpzpi/69gtqMAt4M0HMLpOksmjAi4GUU4Z1KdAq/eZIl4b/OU1I2v0rKWQHyodF+yhZAOF/+Sa2X/BZAh8PcYRAK/9tSIZ86/DqHjjBq/8TmxR6yyP/erOyW6wPn5TSWDv+V498604 TIqlmFgm okQlBCnlm6J8ihrIVqMH8uWvspkw7VVcz/I5OLReSagxbH2nNyEe2KQCi7RE3+8ocHtJc5vPYDxKCU4twDmUI1ilq6bkC1JWYmVqEPo9R7H0tBzRdYS9aKSkUWegJSgo+YvVU2sZHKcF8cVMWwAxiT6LmdsPoTdpgi8TOxgxpE0hMTMwYCHES1dxI97kjzBJGwjGh+HCqcXaRZDzGei3AytwEhcpaxJHgyXJqxmvfu1Lk8cZRnfcz/Y35Q8UAhVb15iRfu860zDYBEkfkbUqCH8DUGw== 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, May 08, 2025 at 09:36:02AM +0200, David Hildenbrand wrote: > > > Which raises an interesting question: I assume in the future, when we have a 4 MiB folio on x86-64 that is *misaligned* in VA space regarding PMDs (e.g., aligned to 1 MiB but not 2 MiB), we could still allow to use a PMD for the middle part. > > > > It might not be possible if the folio comes from buddy allocator due to how > > buddy allocator merges a PFN with its buddy (see __find_buddy_pfn() in mm/internal.h). > > A 4MB folio will always be two 2MB-aligned parts. In addition, VA and PA need > > to have the same lower 9+12 bits for a PMD mapping. So PMD mappings for > > a 4MB folio would always be two PMDs. Let me know if I miss anything. > > PA is clear. But is mis-alignment in VA space impossible on all > architectures? I certainly remember it being impossible on x86-64 and s390x > (remaining PMD entry bits used for something else). Yeah, that's not possible; the PMD is always PMD-aligned.