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 9346BC4706C for ; Fri, 12 Jan 2024 23:04:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB6D38D0005; Fri, 12 Jan 2024 18:04:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C66578D0003; Fri, 12 Jan 2024 18:04:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B076B8D0005; Fri, 12 Jan 2024 18:04:30 -0500 (EST) 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 A09208D0003 for ; Fri, 12 Jan 2024 18:04:30 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7978C1C0B6A for ; Fri, 12 Jan 2024 23:04:30 +0000 (UTC) X-FDA: 81672189900.01.05E7A3F Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id 5508E4001C for ; Fri, 12 Jan 2024 23:04:28 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Av4Gp9de; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705100669; 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=sCXUOVTIXHWdxnQX+KXqJPZOClNl3Kvidy09Hlwr4fE=; b=6D/Vg5IzwrXUnBLAniF7UreHZkiZ819ruvVZwqZ+rEG+wxKnnVB9y9N/vJ2HkAu2oG783z 8k7M1ridogImgU7uPMmWuuisrNgihMuzRzEks0UVYDfvDm56zr/QFcfBVpv9M/9BwWgev+ CoPYXTvNbCxNG3ke+OpewWhDZ9JlqU4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705100669; a=rsa-sha256; cv=none; b=Hbz6H4V9FDx7aAcDY8WfyTLBZd766ffQRTqVrautmgFAT4gB+NLLHq8B/hwPra1h6XQh7P YtBJODYJJST2mqivNPxorjzM0REmZK2UFP8wJ36zOSgE4ReYlgJkXDoiy8IuPUAvZG/jDq sU7pVETWIr0cyparlXx3gZFvGnlgwuE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Av4Gp9de; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=sCXUOVTIXHWdxnQX+KXqJPZOClNl3Kvidy09Hlwr4fE=; b=Av4Gp9desBF+IfZ/bHXiMP5Ngl 0v+1TddVS+l82jaBrLX2JGZ8Ew5BoTL1Yf0KJel+5RoVXsntIN3aLv0KKRt7TpjBf5lCaL555tAbA 8RR/dwUlCHidTUs6L3KYrU29stvGsvHu/3isaTbOeMLvoFYyESoCBF6hgrIonJKlSH6yMbliK8WvG 6Frf0Re1E3QFBe+99tQNKtSIfUggZwVBFoKBKUxi2sRrtC95Sdfz0L6cgUp9KD0EU46wr80d3VbvA GBGe8fbn2WBLCpJrizgdIJIHtx8xWDGC7c3zYz3zDGnJ2L9PkLnQeNJaWO+2pWeMfVQGu3+Om9oTa sDe/9P+g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rOQZQ-0016mt-K9; Fri, 12 Jan 2024 23:04:12 +0000 Date: Fri, 12 Jan 2024 23:04:12 +0000 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: Ryan Roberts , Catalin Marinas , Will Deacon , Mark Rutland , Andrew Morton , David Hildenbrand , John Hubbard , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v1] mm/filemap: Allow arch to request folio size for exec memory Message-ID: References: <20240111154106.3692206-1-ryan.roberts@arm.com> <654df189-e472-4a75-b2be-6faa8ba18a08@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: fp5f7d94aszkdndanupdh4r8ixat4bxf X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 5508E4001C X-Rspam-User: X-HE-Tag: 1705100668-108083 X-HE-Meta: U2FsdGVkX1+Oof6riZnjvAN4crE5FmuaMILKb8FQPV/iujsjwFNhvbLr95y1WnO8dBVgdOI+CJJUcJ3t/HckIWlVz/6S7u69RJyYbBeVo5OZF8peXyJYWe35Q268vuqey1phVGYsegJWu3PT5UR6ETgk/YhRFffRok6/wlJe6HktwkiU+fB47bxHY8UI0JZz55xTDYjUvzFflR4z5jKyk9mNFGiFFOaYPkAI6PoxAWfpb+ITsHOjlY46jZ3/hYjhqzW9SxAnsnFWdREyFCw7B+ZJKdyyg1zLyU07BrTHE3J+rAQlqc68het9/RLeYMWV/kdVu9x/zPNLzStLEZKjDvc6Lhes4K8LHypplJ4e0PYi1/IRyPwYNAhOR9xVBHe5TwIML7EOSFjK2DNbqqGFA5o1ROyWEOrBPj4ged8XZXXZL/lA1L6Bci/1hT7oNsNA4A0lGXlylnU0Fbujw6zvj3Oi1+2ziZvIIkFGaDZnxCp8r0JjEPN14D0tclKttzdGhbEJ2Nd4lMsYE6ciub9SLpYANuxjSJ57fy11RmJJwPk4b4+GRsN8qkZaJ5AROUqqtDvaBoa4jLMrV6MWnHmdPyiQoU96vav7ND3p3yBU2yZ2DHZmseMgixPXGxU/RF0Snnq2yq+PNLDwVKXezRByzmr7ZxcVwpneMzwNXQbFVNXPyPSM/dEX1PtMrtb55mZpF7uqLjbJ3mV05caFioeSGYKH6YEv0d09QyGnh0uBnpar4yYbY6stdnCWZ6xVRyiLnePFLQEGTya6fiUBL3Uc7qc7JQRzjxoEe7/j/xCV/Pm3js/StR5SmBpmWXKTZw4XIlT2CmyNCTTLU4q7/o0NONq+y1qW+3SFKCIP+H7JJkEZTYg0DJQbLCLc/xoQfSt2ECH1vWT6fGr7WlzGLZbspX1WX3tTJ8iu0axErVbgbSfdBPOzensMw/v42iuvBHAWSKLU6sZFhNcEleBYqXL 2pNlpbZo XmIbNHsWBO25wycMSzhNaDMjDWakkmNqDDzse4rYfD5ZpBEIyYt6ukKpr3nzBwquQtzF3bNPIsa4g1h6+Qkjm+ZjaEr36fSdgpbuSrOp6qUbZxNW/pzjfuus4yhUdDz8Q/qav5xbARlxns58qZluXh57GrIUjAEJJfbslKC6g82F5+SGSmekLHXhGSqCOSVsOCy5aEs7XYE0eSacZGDaRcLSRPPzFAWkU3W8j 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 Sat, Jan 13, 2024 at 11:54:23AM +1300, Barry Song wrote: > > > Perhaps an alternative would be to double ra->size and set ra->async_size to > > > (ra->size / 2)? That would ensure we always have 64K aligned blocks but would > > > give us an async portion so readahead can still happen. > > > > this might be worth to try as PMD is exactly doing this because async > > can decrease > > the latency of subsequent page faults. > > > > #ifdef CONFIG_TRANSPARENT_HUGEPAGE > > /* Use the readahead code, even if readahead is disabled */ > > if (vm_flags & VM_HUGEPAGE) { > > fpin = maybe_unlock_mmap_for_io(vmf, fpin); > > ractl._index &= ~((unsigned long)HPAGE_PMD_NR - 1); > > ra->size = HPAGE_PMD_NR; > > /* > > * Fetch two PMD folios, so we get the chance to actually > > * readahead, unless we've been told not to. > > */ > > if (!(vm_flags & VM_RAND_READ)) > > ra->size *= 2; > > ra->async_size = HPAGE_PMD_NR; > > page_cache_ra_order(&ractl, ra, HPAGE_PMD_ORDER); > > return fpin; > > } > > #endif > > > > BTW, rather than simply always reading backwards, we did something very > "ugly" to simulate "read-around" for CONT-PTE exec before[1] > > if page faults happen in the first half of cont-pte, we read this 64KiB > and its previous 64KiB. otherwise, we read it and its next 64KiB. I don't think that makes sense. The CPU executes instructions forwards, not "around". I honestly think we should treat text as "random access" because function A calls function B and functions A and B might well be very far apart from each other. The only time I see you actually getting "readahead" hits is if a function is split across two pages (for whatever size of page), but that's a false hit! The function is not, generally, 64kB long, so doing readahead is no more likely to bring in the next page of text that we want than reading any other random page. Unless somebody finds the GNU Rope source code from 1998, or recreates it: https://lwn.net/1998/1029/als/rope.html Then we might actually have some locality. Did you actually benchmark what you did? Is there really some locality between the code at offset 256-288kB in the file and then in the range 192kB-256kB?