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 33EB1C3600B for ; Thu, 27 Mar 2025 16:44:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 233D6280105; Thu, 27 Mar 2025 12:44:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E4352800FF; Thu, 27 Mar 2025 12:44:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D486280105; Thu, 27 Mar 2025 12:44:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E2D5E2800FF for ; Thu, 27 Mar 2025 12:44:39 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id DD88A14125D for ; Thu, 27 Mar 2025 16:44:39 +0000 (UTC) X-FDA: 83267904678.11.A3E6E80 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id BCC04A0025 for ; Thu, 27 Mar 2025 16:44:36 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tX86Jgoq; dmarc=none; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743093878; a=rsa-sha256; cv=none; b=59w0h9UtBlg11ywT72ai8VIMRpbJuWQLbncpqlBuC55qa63Ck3BRh5cHvE4GXpUgR16bsM YfU6Olu2uyMu7F1hTplo3horzksIpk562bzSl6FSyDjpJPhuAzoj+i3+2mmJ0PXTtY85cn qtwIPlKVkFE9DSA6xa80mROjAMjuE54= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tX86Jgoq; dmarc=none; spf=none (imf15.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=1743093878; 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=MoCqLC0IyhHguklsqlEzr9OrpUUFrOWDPdsoNryKYDU=; b=JKhg7U0A+CF4/M+svHDpiUcjBoW00YeJ9Bv29dkFfPWmJlzm8XtLAQqtB2uHnrijrGPsyK cUmKsXGCw7j2MM4vpFRQdLUEx0bdl7bXN7rTNSeW/5J+CvHZw+b4Pw2Xe8XNonrs7+WRvx 0u50VoYFqHl+oIn02mShc2UbDRcAL3A= 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=MoCqLC0IyhHguklsqlEzr9OrpUUFrOWDPdsoNryKYDU=; b=tX86Jgoq24bhniWrtEPXpkd536 cUmSpefVNuw5pC1Od8arup43Wnt7+0HRYOZoanyEQdX0oJU2QGL5xfloxkFz8kRQrsp5qXMswzpcm 6N4x9LAKCqKwO8lowZUyg7JMY6pDkmDBvJoHIbH+vZK5Eftv03kMbr4oEon5AzyL5LhEdcON3/zXA ORGXhYuo5+I7eAubmfHcetoSzGNeQPVaTZQ2nCwjJ+3LPw9wiJeF3PnIZvz1oAInLzJaTKHfCth7z BLYHE3Kib6e5E7PS7n7ICBAU0KNrjkVE3ee8WJjXwWefDYjcgEz9JHDntUS/0mP8NIoRsj+4aMDGm vac/ZHUQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.1 #2 (Red Hat Linux)) id 1txqLG-0000000DMCf-0N50; Thu, 27 Mar 2025 16:44:30 +0000 Date: Thu, 27 Mar 2025 16:44:29 +0000 From: Matthew Wilcox To: Ryan Roberts 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 Subject: Re: [PATCH v3] mm/filemap: Allow arch to request folio size for exec memory Message-ID: References: <20250327160700.1147155-1-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250327160700.1147155-1-ryan.roberts@arm.com> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: BCC04A0025 X-Stat-Signature: u753uexsm167fs8f8j1pfu49po574o39 X-HE-Tag: 1743093876-619467 X-HE-Meta: U2FsdGVkX1/FVdVaYq12HMtjzlimzCXiLvb7an1njlhUaFNtcHNrwFgKEElF1/6BmilNH7+X5Y9LG2jjoGK5TIacdmtjz/WtXVPbU/zFdBegbUprxJbuWd4KqJgpMSA7o9fB/9ZkJXNabTTGAmh8Ymgsib06N5Qczp17wPRu8tbBNQpiAjExk1Eu/dwcqDhF+GYuOBUwMDospwrPjnGDrnMZ+sMAB023rFdqSCmjSElpo03c5lQw77ysTWJ7znkNG4TNtw7CPvUgpI2ZZQt3Ldgv6axeVz/J+/38eLrSb0eCUUFvMH5UrWCt4GcOdmIkpHT/ddr9CRWhZsy8uY49NYhIE2qZwjx2IW6NDe1SyUNFuDPr2JiChHGcrtEASZQayLF5Np7ljgztoHQhpHfSnmk2vjblMGHGWVR4hPolOPGx/RF+r2ghiVTaoXoPFF04xDK7nIEkA+UtDb+tnOYGMJxRNqVcUVHAiq4VBETN3NFhiLDV2XKK6E/SopkzD5vBh8vlFQw8BPKWHB51stnINqDRlGV+BP2EK7hz+IdSSGajB1WXUvqsjl6en55fkgRMUAJBp3Pe1W9gRmdjCDUxHBNpE8YqGejmHoe5Phv0cuO+JhZudS0LWEVx8j2MaVIkH+8kk51maVHGlHGWSQfe90mh3aOlTBK70K1vaKL8jFLrQKVMduDqRei88a9hyli2rn5fUfsNwqvu4adZ9IloXIVJ1o3IlZlZPkAI8R50IZd4EgyRvA7H492gcN769s3wZOLphVWMEbmkPkFzl9HarRHdOhQgYewihSn4Z9TCFpDGgWIv7JYj4E/5cl8EwXiu41PTGa8cqyyuDImOk6UbNpzAEeYHC0PVuFton5sJtJFmQJGjckIaZXDy8W6ejsNhda4Lu4WTxDrnagLY34y+NwJLbWUe+UUUGVwt//zmfsNvddubsYxg9nJOTjxOFZ8Uzs8b3K/XwufVCPOIbF/ lhRU9AgT HY2Da3Ei6vq/fai0esf4t4iIPd7koFfH26Smo0OLJA/rUndmbOH2ESL0dCAYk2rNs+Pg8kKHAbasz2OeMHDuWzPT0DnMmkHaOMPCf++Ga6dzNQkIAbJ3nuFQj4kr5uQVeiU4GRfkUx6EpW1yX5m+hEGh3OgB+He8PCCFjlqoxFmI19TBmSUovSGDoAOeoPVd8UDJQxHplxm4Az0GnI00DvjinZYVobO+bnx/FS+SK6ks2Kpk= 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, 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? 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?) > +#define arch_exec_folio_order() ilog2(SZ_64K >> PAGE_SHIFT) I don't think the "arch" really adds much value here. #define exec_folio_order() get_order(SZ_64K) > +#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?