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 5D3F6C021B2 for ; Sat, 22 Feb 2025 18:03:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5EFC6B007B; Sat, 22 Feb 2025 13:03:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AE7DF6B0082; Sat, 22 Feb 2025 13:03:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9889B6B0083; Sat, 22 Feb 2025 13:03:16 -0500 (EST) 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 76F456B007B for ; Sat, 22 Feb 2025 13:03:16 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 10A391A1901 for ; Sat, 22 Feb 2025 18:03:16 +0000 (UTC) X-FDA: 83148352392.18.53383A6 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) by imf17.hostedemail.com (Postfix) with ESMTP id 1602A40014 for ; Sat, 22 Feb 2025 18:03:13 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="ZQ87mR/e"; spf=pass (imf17.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740247394; a=rsa-sha256; cv=none; b=wf9RPxenUwN6BqCxsgScCqxwPW4upoMSShxypXMLWr6cvI/ctfXbwqBAni4tFX3p2OrOOD +3bQ4/CwXkQ4D393cc2no0Jjq+mM1LitQIg4fjEmuKo25WiczOPiuHjEqvo3qh9EcGyb8q gjipO002fGX4u3+l/IUidJHuUmFoBic= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="ZQ87mR/e"; spf=pass (imf17.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.183 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740247394; 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:dkim-signature; bh=3GdREV2SzieyWUR0Jf2M14Uc9ffUtrBLAjadT4w1/XM=; b=aaK6jd+BNvJpGTT0phrve/ULD+lD05AQPCi292uN5xLgLCfi441wq9SYzxAN9ADiZ0Cb9g 5XMrfQATNEiCZIqChTv187C78O0KfxtIFoe6eaaHtzlh++sugeu6qf07aRKtIp//VFetMf AyCzW7T6CJShhhIt+mQY57fIvAqpqG0= Date: Sat, 22 Feb 2025 13:03:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740247391; h=from:from: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=3GdREV2SzieyWUR0Jf2M14Uc9ffUtrBLAjadT4w1/XM=; b=ZQ87mR/esWE5rtddEqyNRbo2Nv53Esn//fBOS0u5zYDstrTXhs04m6LYk8MEAEOc63LPDD hadXEbBPEGV08Dt6H6TNth0fU3Ow3Y41YrzQ32vpJxoJtFbFHJtjnTp4eDorN6Vd9qk6X0 5BTkdkwHrhyW4VGVJiVmAGacIycey1E= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Kalesh Singh Cc: lsf-pc@lists.linux-foundation.org, "open list:MEMORY MANAGEMENT" , linux-fsdevel , Suren Baghdasaryan , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Juan Yescas , android-mm , Matthew Wilcox , Vlastimil Babka , Michal Hocko Subject: Re: [LSF/MM/BPF TOPIC] Optimizing Page Cache Readahead Behavior Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: 74qnr9phrzjxo1job1n4nwapmczt6azc X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1602A40014 X-Rspam-User: X-HE-Tag: 1740247393-75709 X-HE-Meta: U2FsdGVkX1+NS63hc93yGeajfBNDPKw9dUqsf5f0iC8RF3+zioHpnB0yRvkNH0joAK4tfHnRZDFbNfilCFHVv7Tp3nvgBULbkKmdLk4YgQaQ5NH4lWDEqKBwxY2+hOiB9YzPGfl0iX6HTCxrOFGBD3JMlB4ZXa6dr6twbizHyLZCKwQTRXc8dr44D24Ji+clOH/BO0vuUDqRIsWsJdwsPgmGVIJzTh/cf8jjmuO/JKouEgCoklkjuFSbDM/YUD6G84SRi7TlHwk5/akVxpeqaARUCvi0wGa2oTaXXlRjsbMAnitMkb7fVRChIYFpsHsqkYYaevKHUx9TKqnFVVHqvN9aEzfWskBWlqcGvkKj3i25xL4ARFfV4CMeKMB3HXRh7KlZG1qTTuWxgWTRf/JimZJBsBlIq6c/6SRVqelmetxSdQrrQAvjfuKi0P6JkKb0mht0UHvDADchitVMyf6VMaWVB6EExGADZNhWwtldsHEnLtgpIPVjfHsmoueocxteI7O2lnQcCn/ldq4lm9VJGvw/m5k/snLYM/5f89W6qc/PA3BulYLvfqnWoLY+GY5+1A6QnzTMzZ532tNes5D5PW5y0APKRzF7oJAppOtrb9N6m8x5UIErByboDF4hIbdLRS85rAVU9JAFRKw7Nep+TH+21WJL5TuTOZ0/CzzXjnUj8YjOn1G1xXOimLxJxO2BoNSUdJcW2GFAseWJUH4+5PlzSYa4aWntO0JVqLwvZIfAhzlFP60xJiel6AV7C1Ts+h1V7MCBEamUf2Bdn59ECjOgvu/PIBUYGwZxmhhthG0A/dHZCMqzjJ3hDRCw0hjCml7u+vIF4Hu9/dB/lIUWjHHzJxw7j+hbSoR+bpZKpySBaUSQ9/dwh9VgW+U+vIkHR9wAZFGRLYLSKBwnzpOUbNU/bR5fp+mNfahbh47RBuqtHoOtJ4fpoiOg8tt4L8mSHgidvRkVD7flMLUTdpU UAxd2o97 yoH7gY4Ms/S3lQpXzTFPLzU3qWFobnjOZk+1Ol7ZVDQ8Hw80fIdMjSXNevSGs7qnJD3INdV1r0Bnhy6roaJCe4EEIIzTZ1iVDAIaGofnB4g0p2aajX0IQ07fHkMekqyrXCbIvX2p2fnebx+qOL7DUwND1W7huBHnPuj3CEJiFP48/Qp1dO9UcT+mSsJjuwQ9Urzo/D+MLTasBmRc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000944, 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 Fri, Feb 21, 2025 at 01:13:15PM -0800, Kalesh Singh wrote: > Hi organizers of LSF/MM, > > I realize this is a late submission, but I was hoping there might > still be a chance to have this topic considered for discussion. > > Problem Statement > =============== > > Readahead can result in unnecessary page cache pollution for mapped > regions that are never accessed. Current mechanisms to disable > readahead lack granularity and rather operate at the file or VMA > level. This proposal seeks to initiate discussion at LSFMM to explore > potential solutions for optimizing page cache/readahead behavior. > > > Background > ========= > > The read-ahead heuristics on file-backed memory mappings can > inadvertently populate the page cache with pages corresponding to > regions that user-space processes are known never to access e.g ELF > LOAD segment padding regions. While these pages are ultimately > reclaimable, their presence precipitates unnecessary I/O operations, > particularly when a substantial quantity of such regions exists. > > Although the underlying file can be made sparse in these regions to > mitigate I/O, readahead will still allocate discrete zero pages when > populating the page cache within these ranges. These pages, while > subject to reclaim, introduce additional churn to the LRU. This > reclaim overhead is further exacerbated in filesystems that support > "fault-around" semantics, that can populate the surrounding pages’ > PTEs if found present in the page cache. > > While the memory impact may be negligible for large files containing a > limited number of sparse regions, it becomes appreciable for many > small mappings characterized by numerous holes. This scenario can > arise from efforts to minimize vm_area_struct slab memory footprint. > > Limitations of Existing Mechanisms > =========================== > > fadvise(..., POSIX_FADV_RANDOM, ...): disables read-ahead for the > entire file, rather than specific sub-regions. The offset and length > parameters primarily serve the POSIX_FADV_WILLNEED [1] and > POSIX_FADV_DONTNEED [2] cases. > > madvise(..., MADV_RANDOM, ...): Similarly, this applies on the entire > VMA, rather than specific sub-regions. [3] > Guard Regions: While guard regions for file-backed VMAs circumvent > fault-around concerns, the fundamental issue of unnecessary page cache > population persists. [4] What if we introduced something like madvise(..., MADV_READAHEAD_BOUNDARY, offset) Would that be sufficient? And would a single readahead boundary offset suffice?