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 E8CEAC3600B for ; Thu, 27 Mar 2025 20:23:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 061FF28011B; Thu, 27 Mar 2025 16:23:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F2D54280117; Thu, 27 Mar 2025 16:23:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCF5A28011B; Thu, 27 Mar 2025 16:23:22 -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 BBE37280117 for ; Thu, 27 Mar 2025 16:23:22 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BC68F1609F4 for ; Thu, 27 Mar 2025 20:23:23 +0000 (UTC) X-FDA: 83268455886.24.9DCA3E0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 8213E1C0009 for ; Thu, 27 Mar 2025 20:23:21 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743107001; 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=PhHAe+JTvzR7RyuUU9MBGaQgXXLZr3phu+/ywf4rw9U=; b=CKbb7cg4kH3GsLGAIX/eEz7Cb58/7P6nKetAtvCnFsXF9uyygOzi73cY0pUiAntvDNlY2g /E4FKMDEdxqTSSptfmzVY40K2bU1Gi1d6tpeOvsa8gp/m/hFSONa/QTTcDqN2752NjmFA5 TjzF7nMau6ADynXGPVzpc9ZhrXPR4LI= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743107001; a=rsa-sha256; cv=none; b=apHeYfbZlAqE7UazJIs6vf91XAPiVgTStMQ9geL2ES+BMgrR4Rpd/laa9FgsFdTn5ZXupb B2641OYb8gliVwKDC5rRKuO5Nhiib87aFI5NzSgvLxlbB02VNqn7MEQ3FtikGB/7Ez8kof 1+p2TVNvpVdnt4kkpizygcwmW0TnSRA= 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 7C4271762; Thu, 27 Mar 2025 13:23:25 -0700 (PDT) Received: from [10.57.86.101] (unknown [10.57.86.101]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A0CEA3F694; Thu, 27 Mar 2025 13:23:17 -0700 (PDT) Message-ID: <5131c7ad-cc37-44fc-8672-5866ecbef65b@arm.com> Date: Thu, 27 Mar 2025 16:23:14 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm/filemap: Allow arch to request folio size for exec memory Content-Language: en-GB To: Matthew Wilcox , Kalesh Singh Cc: Andrew Morton , David Hildenbrand , Dave Chinner , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org References: <20250327160700.1147155-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8213E1C0009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: fdxuc9u6o7m8tnn4ecagrfmxjyrzsjkf X-HE-Tag: 1743107001-806317 X-HE-Meta: U2FsdGVkX1+ZcXn3aGvaRszrJ5LcUz0P5rYmq+krA9/K7XZbKs1mpmzkcwyA29cVzKGXZFdL02zI0aJ4NkoDyPvqPYtP1eszl3uUg7bJlfyOippclKsxHGMm/lkd40WPv1mpKdC9kn+OO/7wHBmiW+GfRmb6KKb0Q5DIjxp9Uk/qrqgYbbu0fF401j91/KN1J4iqf3/q54Vm+iX/5Lb3XKI9lUXyPwCaDrtAfOP25jJbGIlpu0YD/dpQ54X4sJmv+G7UBLzKNlpVmugfaf0n29NcqBpnDYXMcyLni0qeNXNJTa82P02LNNBLwUMnfj85/oY+3rk3DdwcD6L0ZFbuV6wATsXj8aHFSsKvcUr8NWuyqa4OxRW49kBZFgnVlQRkhkxcwForaxENudFBHAEQtXchKkmzJKis0KFtsTt00fIENAndCRt2bAjtTuIhitxw+3pA4zzwH3+0n9AIzG9d3lVPeUGv4Fr36CY8R9sxRlIND5U1QGd3yffWRE5DKCjPgcjLDbugCrsg6EOxC/5Noj4IvfMSqMVyVZIdOZuQqZEyaoBbjRaOljS0igz+RKvsynykNUd4NCpG5jrp7kbvGtu/o3wAm1cFXLnbVocPMkozOEkmLAorP+PVWc2t0HRLVbbemUla4gNP89F3i+1UIb591wra2u/zqfaqt9w/E3KYkLHu2IX6Zv+tnXmvKUi6tXm57lYTgsKljJeinD8kOIoJYKVcll04kUcwbYrShBrI8teyiYGlS7WLGKYO3T6bJiauxAc6zn6o2YOqI/jvuzlxL7TbdJPbE9LYh1YWvN8A6ZmaMECSsp5mu1wFj6ak3rTadFlgEeDhq7IdzO28n9S7IeeU3LfuAQD0HEniorWI+LH43adbNqoVi9WITlsYYle7PxUY1i8aFK7r22i0gNziLM5Akx6U3fjwYT6ryI4ly3B33Q+4T6nxX2H40QKDv4RzQ4kFXzHzAhOxBrX srIlAHUd oaOgsjoN1KIidj2A61qNIQcNedXe5WTra5cvchl6bAIXlMlcO+ZwzsVx1X0Ztzbg8S1l4mzHRgsTbxD8k3vSBw4t1XnRw+G1lljuBV7+f8xsDRmUc6UEmGHwvUi0irLEGVCau+NyCaScnESs= 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: + Kalesh On 27/03/2025 12:44, Matthew Wilcox wrote: > On Thu, Mar 27, 2025 at 04:06:58PM +0000, Ryan Roberts wrote: >> So let's special-case the read(ahead) logic for executable mappings. The >> trade-off is performance improvement (due to more efficient storage of >> the translations in iTLB) vs potential read amplification (due to >> reading too much data around the fault which won't be used), and the >> latter is independent of base page size. I've chosen 64K folio size for >> arm64 which benefits both the 4K and 16K base page size configs and >> shouldn't lead to any read amplification in practice since the old >> read-around path was (usually) reading blocks of 128K. I don't >> anticipate any write amplification because text is always RO. > > Is there not also the potential for wasted memory due to ELF alignment? I think this is an orthogonal issue? My change isn't making that any worse. > Kalesh talked about it in the MM BOF at the same time that Ted and I > were discussing it in the FS BOF. Some coordination required (like > maybe Kalesh could have mentioned it to me rathere than assuming I'd be > there?) I was at Kalesh's talk. David H suggested that a potential solution might be for readahead to ask the fs where the next hole is and then truncate readahead to avoid reading the hole. Given it's padding, nothing should directly fault it in so it never ends up in the page cache. Not sure if you discussed anything like that if you were talking in parallel? Anyway, I'm not sure if you're suggesting these changes need to be considered as one somehow or if you're just mentioning it given it is loosely related? My view is that this change is an improvement indepently and could go in much sooner. > >> +#define arch_exec_folio_order() ilog2(SZ_64K >> PAGE_SHIFT) > > I don't think the "arch" really adds much value here. I was following the pattern used by arch_wants_old_prefaulted_pte(), arch_has_hw_pte_young(), etc. But I think you're right. I'll change as you suggest. > > #define exec_folio_order() get_order(SZ_64K) ooh... get_order()... nice. > >> +#ifndef arch_exec_folio_order >> +/* >> + * Returns preferred minimum folio order for executable file-backed memory. Must >> + * be in range [0, PMD_ORDER]. Negative value implies that the HW has no >> + * preference and mm will not special-case executable memory in the pagecache. >> + */ >> +static inline int arch_exec_folio_order(void) >> +{ >> + return -1; >> +} > > This feels a bit fragile. I often expect to be able to store an order > in an unsigned int. Why not return 0 instead? Well 0 is a valid order, no? I think we have had the "is order signed or unsigned" argument before. get_order() returns a signed int :) Personally I'd prefer to keep it signed and use a negative value as the sentinel. I don't think 0 is the right choice because it's a valid order. How about returning unsigned int and use UINT_MAX as the sentinel? #define EXEC_FOLIO_ORDER_NONE UINT_MAX static inline unsigned int arch_exec_folio_order(void) { return EXEC_FOLIO_ORDER_NONE; } Thanks, Ryan