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 A6CB7E6B278 for ; Fri, 1 Nov 2024 13:55:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EB536B00B9; Fri, 1 Nov 2024 09:55:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 274DE6B00BA; Fri, 1 Nov 2024 09:55:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 116716B00BB; Fri, 1 Nov 2024 09:55:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E88236B00B9 for ; Fri, 1 Nov 2024 09:55:42 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AF3DF140622 for ; Fri, 1 Nov 2024 13:55:42 +0000 (UTC) X-FDA: 82737673872.29.5E11517 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf13.hostedemail.com (Postfix) with ESMTP id E91662000F for ; Fri, 1 Nov 2024 13:55:11 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf13.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730469221; a=rsa-sha256; cv=none; b=CVgMxFxRha/kKLOCpFCt042cyC+TtdeH9HKDIHu4/nNLbuaErVOQBbg2+YPf8Gmfj45TAD RKpqMFR8mmEsDB58yErV+1D0vxlgjDyCVI9KPkfi+J9aq0aTT0OdTUrT2nhiLr1QdIARLp g7aiCGBKF9ttJBR4aP3RMV+ez6Z3C9M= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf13.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730469221; 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; bh=Vena6H1phr3MgeVL8fFEujbOUBs119swW41Ew9CXTwY=; b=FI+HEfaYppf22jYTXEP6CdoiOXvQiNVq1Ht1o7ilr3OY1+5AhRjyPxopQwq3A0hfntOjM3 w18FunuORiU2T0thiKwPaB+SyuM3kwMQnT3QUM3/IqpPlvRPewi6K7T9fQQ+XB8CD38N8/ duqp1M4IMQ1GvIR/bptVYxxqg20YvSs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EEFB55C8A05; Thu, 31 Oct 2024 21:06:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3477C4CEC3; Thu, 31 Oct 2024 21:07:18 +0000 (UTC) Date: Thu, 31 Oct 2024 21:07:16 +0000 From: Catalin Marinas To: Ryan Roberts Cc: Andrew Morton , Anshuman Khandual , Ard Biesheuvel , David Hildenbrand , Greg Marsden , Ivan Ivanov , Kalesh Singh , Marc Zyngier , Mark Rutland , Matthias Brugger , Miroslav Benes , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v1 00/57] Boot-time page size selection for arm64 Message-ID: References: <20241014105514.3206191-1-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241014105514.3206191-1-ryan.roberts@arm.com> X-Rspamd-Queue-Id: E91662000F X-Stat-Signature: 4h36949kngmjdjybjfi3rrackd7yp734 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1730469311-556342 X-HE-Meta: U2FsdGVkX1++oUI84FYnnhipIA9hR0lAGiQeyu4VHgbT86xoqx0XfE3k2vCIP3DPaJD958zmIEnqot/oLEj6p5jfT4ePpGBcd51NSzwWx0dQ5TCfhby3qSYxPOwPuLBrOSOlF7Gghr0x61CClVZqlMlMkqOFrPRheKmkbDunA+GXqCY5JFG4qdbCulxKJvQsTaPUztG8uX0UT9z/Ujjadv0K+mV2GEJk2Ej58a5i13cLAAf5deOGIWuZRW4h4baw2Payo+MPaqhxQOjtYzRGd9TvW7gSaq03NUUO9vM4R9RMRjmOUakf9cpJvVtkVjxSbw8oViIrtuL30JJgd1oPzO1KLSZKygwGBE23R2GCIeKlHw0d6ApVzjKlvNQhkm7NIC+huZg0iJMxipZ/C/IMINkwA+RBPGRPyUoMBIi9Z0ZU/44F5LFyFl2jZeNQBvUv9lYrDFJMUfg8o1Utnz/yzuXvTrUqTLm0/qjk179K8Wg9gBlzyOa2HtSeSoW6uvbSz7Fccy6n++kh8sEkc8Mb7hiEn5u5kLRbB6TakcCXKHkle0E+RCZVmAiAE9Amg69gvasV8xbCyBnDR58unH+4nTWWphigRn8ghfJsGg3mdm3AG/9AOyZn7iflBsN6ScfN5HYfSnDu2bvOvfC/dTSvsYdunUNJYb4GvEFwUTXYCbvskepZFVssFQW4mloEqfV2/HWg4oGpNYBd3N2HQcO4mIZFGPkDHVXFDoXBOQbhAs7Qy3FT8lkQBvNdoVEF4hqhkckIrG+zGQf9CiF2GzAokFZCxHmDZ14Z1yES173f6l9b7eC/5TnQbkegYxlymhLClOjbZ3CY9n/G9loxCw96XeI57JZU/Va9R7s7LAgQDQTv3aCjfiBqyridZssG63w1HszB5FSucqVVi8asU/m3wNweymeFn9EoJdugMpfm3f/ZwqMusvswyef5y6oeFML1zPJDQXPhM+rmJAdwmPB YqiWFS1X HbOvSu7xXy8+dwPiIa0/8SHv0dVOFxqyzwnobixIzNspTZGoI80oPFqj+PcbWA15KDlgetW9G+Zq19bfUeRAdM+yHdOTgXm9JR+l32vie8ZukId7DHuWlNpYR6/ZP+MSTQjaavuPD2UT+WyoCL0ivXSjgIojM791aKY5cngi2Wm7xbiyfP3giN6p7+BA+47msAhZ9EdyUh+/tb9Cpba3vu7ykIOJ2DPWUafCc/YtVz1j2pq63PNiGRALD4ybGmiGq0SWkdDXwphQGxdOc/8LlsVgjWGO6ZdE2uAbYqHrlG8fCgePbLHK/cZqNMt7ElDb5yNN1wLnmwF8VQ0I0CRY9wXQOuwQJjPOkikOS 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: Hi Ryan, On Mon, Oct 14, 2024 at 11:55:11AM +0100, Ryan Roberts wrote: > This RFC series implements support for boot-time page size selection within the > arm64 kernel. arm64 supports 3 base page sizes (4K, 16K, 64K), but to date, page > size has been selected at compile-time, meaning the size is baked into a given > kernel image. As use of larger-than-4K page sizes become more prevalent this > starts to present a problem for distributions. Boot-time page size selection > enables the creation of a single kernel image, which can be told which page size > to use on the kernel command line. That's great work, something I wasn't expecting to even build, let alone run ;). I only looked briefly through the patches, there's probably room for optimisation of micro-benchmarks like fork(), maybe using something like runtime constants. The advantage for deployment and easy testing of different configurations is pretty clear (distros mainly, not sure how relevant it is for Android if apps can't move beyond 4K pages). However, as a maintainer, my main concern is having to chase build failures in obscure drivers that have not been tested/developed on arm64. If people primarily test on x86, they wouldn't notice that PAGE_SIZE/PAGE_SHIFT are no longer constants. Not looking forward to trying to sort out allmodconfig builds every kernel release, especially if they turn up in subsystems I have no clue about (like most stuff outside arch/arm64). So, first of all, I'd like to understand the overall maintainability impact better. I assume you tested mostly defconfig. If you run an allmodconfig build with make -k, how many build failures do you get with this patchset? Similarly for some distro configs. Do we have any better way to detect this other than actual compilation on arm64? Can we hack something around COMPILE_TEST like redefine PAGE_SIZE (for modules only) to a variable so that we have a better chance of detecting build failures when modules are only tested on other architectures? At the moment, I'm not entirely convinced of the benefits vs. long term maintainability. Even if we don't end up merging the dynamic PAGE_SIZE support, parts of this series are needed for supporting 128-bit ptes on arm64, hopefully dynamically as well. Thanks. -- Catalin