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 01CF6C021B2 for ; Tue, 25 Feb 2025 06:45:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7DAD56B0085; Tue, 25 Feb 2025 01:45:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78BA56B0089; Tue, 25 Feb 2025 01:45:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 652176B008A; Tue, 25 Feb 2025 01:45:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 429C36B0085 for ; Tue, 25 Feb 2025 01:45:28 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DBFDD1A0C29 for ; Tue, 25 Feb 2025 06:45:27 +0000 (UTC) X-FDA: 83157530694.12.9B58A62 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf07.hostedemail.com (Postfix) with ESMTP id 10AAA40005 for ; Tue, 25 Feb 2025 06:45:25 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zecqIOcP; spf=pass (imf07.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740465926; 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=pCIjwPddBZtZ98G5Kvpo03f+UnGFfP+BAS96DDKg3XY=; b=42NaKT8VXD7tDRJSBpzDpum3vKFiyrKdZdtATNxQbL1E+u8R2QSiQKtPcSwAjoy7AlBrIs GBOpcp+7/n5+tMLOI8bJSFvYk0lzcFb3IGNDtsp+VSyrQhjOuwEBU1TP0HhvwBiTJWmI4y BcesR29oCWZVEro0ahvptkJO7kRbfk4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zecqIOcP; spf=pass (imf07.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.182 as permitted sender) smtp.mailfrom=kaleshsingh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740465926; a=rsa-sha256; cv=none; b=Uicrbxl2i5QRCyGvWlslGQ4+laMUFHf7Ay4xYCdhR20vYoLIWFuqOLCohR/w6/E7BPB2v8 m4Ome6leyIxhuqCICFmRagt1EnTGIEUU/W1kucGu9LyuJL5QYlDLPQAiPdoUbr9Fo1oYL4 XdZOQrV9zHSkPsSHiakPxvu6C+Yg0kU= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-221ac1f849fso74605ad.1 for ; Mon, 24 Feb 2025 22:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740465925; x=1741070725; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pCIjwPddBZtZ98G5Kvpo03f+UnGFfP+BAS96DDKg3XY=; b=zecqIOcPpnwowr1sLMIZX9iIrAjia2mB9LuhlFlksYhody7F7UkBpnQ07wYo5l+ceA 1fgkbPr09F/sSA2TFQPg5tuF0I3BnlpkFeP36Nl1hglZ4rBMe8tYzXtRV2gofSU2V4zy mchjpiGOywGgNXZ59pescm1rr4kQw0xW5sYb9bz48X/Fn47/ccxDGOU9PBd9SAW3m+pY uvX0fyzC2g2lHGdvS+jv7ONhVdv+5LRn++KsxlNbxjKVsxqKVkaRfzllp1BHO7H9h/fX Qpc4f8HV/lEhYk23f67PxDH15M+fvpoFPW4GFdzeYYzzyTnsdi2jh7xxejA8TbwDq+a8 xLTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740465925; x=1741070725; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pCIjwPddBZtZ98G5Kvpo03f+UnGFfP+BAS96DDKg3XY=; b=GY2fETdjDytCsmKRMg/mvL0+TSiWBnNgTOjL5pUCpkU6CNtjOF/r23amtaV5sv8en6 6mCa9Saxgr45cR57GrP2+6SdhX9VgbLVV16uO5jO5N2FmNJnrhNVKz5jBuMPzfm4pXD0 OqZKOevDAH2Lvn46pMYiNZFEiLwq//VDjfCX5kSn9ftcSf2VWHRQcXmaoUkryE8ZhB0k ZSG2zgSO0MFv8dPjfEKxYrr8aGUGLw6bkGhLOcRLfJTEceoVe/38MlxJWdtNIWgL5lqa 5RHcTlyHd18AqrSVg5Pq+gWRCGEru7JLzcomPjL16CI1beEywMFc4MQhvGMBsKYMNxgm lDrg== X-Forwarded-Encrypted: i=1; AJvYcCXwoqppV9lemq3bnAwIsSut/5rI44cfcoazwkD2mVgI4iPNpp3Y4d9jAJSznmVtno5DBgH3gaPjUg==@kvack.org X-Gm-Message-State: AOJu0YxMQToFx/BBVYurFG4PmPFwYtrXZjoIZvzJB/Eg9tNSmVgVYocQ JJ3T+TyS8kF5CCWvNrKLjmZ6kAGjGt5JOtXRJNHP7EN2meTJ0ZNa9F7Lz7krW/GxC0TWEgCkQtq efYd5YiIKrmER/iO8wA+fs2SFmR2HTFn2lpYq X-Gm-Gg: ASbGncuEWzfTslO/PDjEm85VY/K+fjltxcij0qUeZUJjkhi25yRhuPheiW8kCAw3Hqj UxdQ11Nk5PtcAoreQo4rfcckPipAkr85R5uuR11fVrotW5dD/J1W6gRH609M/439oun+Z7+jxPj oeOQQBnhUXYiRv21nJYoYCqHuU9UKo+PgKAuaG2QHx X-Google-Smtp-Source: AGHT+IH8FAwlBuc4BTvCIoh7/sxCgvcbGAH3JFcLbj9b9AI6osK5eUCXs3hyV61fgxFQvevFmy3bLci+Tr2nNtbhFjM= X-Received: by 2002:a17:903:2346:b0:21f:44eb:80f4 with SMTP id d9443c01a7336-22307a2e210mr2241375ad.4.1740465924751; Mon, 24 Feb 2025 22:45:24 -0800 (PST) MIME-Version: 1.0 References: <3bd275ed-7951-4a55-9331-560981770d30@lucifer.local> <82fbe53b-98c4-4e55-9eeb-5a013596c4c6@lucifer.local> In-Reply-To: From: Kalesh Singh Date: Mon, 24 Feb 2025 22:45:12 -0800 X-Gm-Features: AWEUYZna92Ohm2ndCe_59qlckF0s1qouROgIVUdKUo4JCDeaGW4PzL-5UlPruj4 Message-ID: Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Optimizing Page Cache Readahead Behavior To: Dave Chinner Cc: Lorenzo Stoakes , Jan Kara , lsf-pc@lists.linux-foundation.org, "open list:MEMORY MANAGEMENT" , linux-fsdevel , Suren Baghdasaryan , David Hildenbrand , "Liam R. Howlett" , Juan Yescas , android-mm , Matthew Wilcox , Vlastimil Babka , Michal Hocko , "Cc: Android Kernel" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 10AAA40005 X-Stat-Signature: 5obmodwinzztgctofb4f5akstqgbsb7i X-HE-Tag: 1740465925-608137 X-HE-Meta: U2FsdGVkX18Sykbhrq+hK0T3lYTjO6dvomHa6Tt6M6+bXWSxFfPQszADT/w+CsD/5Z9aWWzR/i7OagKVzgn99NEjB1TxU45gfLw/Q1ASvZwo0W5XY1bssUlnrN2dNjItTbOKEwza7bGdD1pdVF/rUqI60MgF4ymw5C2quKFjWSZ8c4UrOC+srJG7Hy4GjIybvMD0gYPQKA31m7qMf02lnLKobvDcmpUNTUvcUiHqZeyhVN3w9pB9YSl+5rBZqhbmnyjXD58PZgdG1vbBZ6/a3KCiqAqPig2+fOauRn31UZjxq2uDaX2ri8jTr6LgWChiLpKs9+eoXIINddmb83/tO0LVfZ3K7WFa7dp5EtwSq+QBHz0tRSQpfY7Kr16iYTcJ08m5VsdvvPG5NYbsICkZpvNd9l2bTl42IyNTrXb5By34cCy3TXqUo8rv2P1EFe2VIOMVcnJWwhvGtAGzmH2/8uex4dKKxrJMJYMS40NESUqEWod6IWDWaTiBX6I7vKW04o8WjUUf3m74RYbVQ88HxWXY9U29e9l/ISIxMjXjyL6Cani8Dv2XaYyHd8x08lvCa6SrAGIat5zZ/UU2pSGkAsA5G8+iY0XPLtPsxRlN6Y3+DBX+Xm70d0bcv0ZFbFTYU6YU6f+fwJPDJ6hqhN3wgYNDqiiXO3k5bdu5AIBxOf6gB0yFNOor0rhbcF1uqdnIz7WoPGzvBy4eG7PAyQi3nyiQn8uetXAJCl03gGyNGBvFBAaIv2MIsHPCFRuP0P1r6U+7x19Z2p+J3xA3AnWkr9y7SRAkk1vaOrEpcLYxfY+332f8ucBKj4y5UBUMBBchXI3kPV4PH5aIyE6lbQS3lkf1sQ9HXEWXJSKwlkZwVS2k9huduOI452osoDApTuIxBsiDhl6CM8NcBTGM23/CJXAIp8e7gDwM6piknd/XoHniSQjem3ZsS7KuGpYjyDbyxgt5S6ptTu2/khH1DM/ q/RT8ZbE zh86rMegVgNtordpuxLAYrj3AFKU7JLzZ7zju+Amsig7bhtgAO6/c9wrwhIbtF43pof303kMUcENvmmmhiRFj3ehX/IUK2gxDosKdjY58JIUfw4TqC328BJqBTkl0x399xxYADxMbMlYCIjTxkaIu7qwMtRnFhB/M1F7p5fCGlu6WuS5XzJ57qxTKp9ASM5Vor/kW/djpe5ivc+8nWz1acf/BH+iTm99+Izttksde6jNg8u1Fzdxqb3fVbR/SXc18oqLbb7O/wTeJRaXSJbjCkLVHlLODEkSff4HwOqRmEzY20aZlt3WITK4LpF4T/4xKGq1258pl6yKC3TaxBT+WbLTEPw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.002263, 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 Mon, Feb 24, 2025 at 3:56=E2=80=AFPM Dave Chinner = wrote: > > On Mon, Feb 24, 2025 at 01:36:50PM -0800, Kalesh Singh wrote: > > Another possible way we can look at this: in the regressions shared > > above by the ELF padding regions, we are able to make these regions > > sparse (for *almost* all cases) -- solving the shared-zero page > > problem for file mappings, would also eliminate much of this overhead. > > So perhaps we should tackle this angle? If that's a more tangible > > solution ? > > > > From the previous discussions that Matthew shared [7], it seems like > > Dave proposed an alternative to moving the extents to the VFS layer to > > invert the IO read path operations [8]. Maybe this is a move > > approachable solution since there is precedence for the same in the > > write path? > > > > [7] https://lore.kernel.org/linux-fsdevel/Zs97qHI-wA1a53Mm@casper.infra= dead.org/ > > [8] https://lore.kernel.org/linux-fsdevel/ZtAPsMcc3IC1VaAF@dread.disast= er.area/ > > Yes, if we are going to optimise away redundant zeros being stored > in the page cache over holes, we need to know where the holes in the > file are before the page cache is populated. > > As for efficient hole tracking in the mapping tree, I suspect that > we should be looking at using exceptional entries in the mapping > tree for holes, not inserting mulitple references to the zero folio. > i.e. the important information for data storage optimisation is that > the region covers a hole, not that it contains zeros. > > For buffered reads, all that is required when such an exceptional > entry is returned is a memset of the user buffer. For buffered > writes, we simply treat it like a normal folio allocating write and > replace the exceptional entry with the allocated (and zeroed) folio. > > For read page faults, the zero page gets mapped (and maybe > accounted) via the vma rather than the mapping tree entry. For write > faults, a folio gets allocated and the exception entry replaced > before we call into ->page_mkwrite(). > > Invalidation simply removes the exceptional entries. > > This largely gets rid of needing to care about the zero page outside > of mmap() context where something needs to be mapped into the > userspace mm context. Let the page fault/mm context substitute the > zero page in the PTE mappings where necessary, but we don't need to > use and/or track the zero page in the page cache itself.... > > FWIW, this also lends itself to storing unwritten extent information > in exceptional entries. One of the problems we have is unwritten > extents can contain either zeros (been read) and data (been > overwritten in memory, but not flushed to disk). This is the problem > that SEEK_DATA has to navigate - it has to walk the page cache over > unwritten extents to determine if there is data over the unwritten > extent or not. > > In this case, an exceptional entry gets added on read, which is then > replaced with an actual folio on write. Now SEEK_DATA can easily and > safely determine where the data actually lies over the unwritten > extent with a mapping tree walk instead of having to load and lock > each folio to check it is dirty or not.... Thank you for the very detailed explanation Dave. I think this approach with the exceptional entries and the allocation decision happening at fault time would also allow us to introduce this incrementally for MAP_PRIVATE and MAP_SHARED, should there be any unforeseen issues MAP_SHARED ... and file_map_pages() would already correctly handle the exceptional entries for fault around ... --Kalesh > > -Dave. > -- > Dave Chinner > david@fromorbit.com