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 70517C36010 for ; Wed, 2 Apr 2025 00:14:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86BCB280002; Tue, 1 Apr 2025 20:14:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F48E280001; Tue, 1 Apr 2025 20:14:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6944F280002; Tue, 1 Apr 2025 20:14:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4B4C4280001 for ; Tue, 1 Apr 2025 20:14:12 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 23ABA576D6 for ; Wed, 2 Apr 2025 00:14:12 +0000 (UTC) X-FDA: 83287181544.12.5FD21FE Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) by imf18.hostedemail.com (Postfix) with ESMTP id 338D71C000B for ; Wed, 2 Apr 2025 00:14:10 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=w19JVmPD; spf=pass (imf18.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.180 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=1743552850; 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=YWQ2ocRDk8UrD/kB4KvMYAJSx6KLCBvwU+MsxS/somw=; b=wKPvF3qL5sAhynCjLd1efHC4fA+DCrwhVh22ta1kwc3A7kwbmjtvmWitwI9U32sQ+N8PUL P9EJ2tLn9uf5g3pKB9952rj67GFxBvVunye812f4TlhbRfss5WIH4mKBiOVkouPsMAZqAR YJ5vA8X5mtVI51SAixkUDZVS4AV0lF4= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=w19JVmPD; spf=pass (imf18.hostedemail.com: domain of kaleshsingh@google.com designates 209.85.214.180 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=1743552850; a=rsa-sha256; cv=none; b=TwUsMp1wFJtQsunUftpmeGEnxjeDiftbPqycNU9CS8CB77b3fddIDdQwZQtvhO3MOciOQO Ycb4pvyxQDFf5vyeBdS35r40uU3uEtsXo2cs2m3pebdc4tvrMebY1Zv6U7Dg4X/h9uqkyT 5Bcaft25YUQ745Q+ZWJA60UCJtAhKhA= Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2263428c8baso43245ad.1 for ; Tue, 01 Apr 2025 17:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1743552849; x=1744157649; 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=YWQ2ocRDk8UrD/kB4KvMYAJSx6KLCBvwU+MsxS/somw=; b=w19JVmPDKM2h+0YPd2zOjPes6OuSP+zI/oj50xl0rKGbxbs5JM7Sk5+wGKWqqHW62c KK6AjWBJkc4ZdnL3ix/BleNb3N09yH++ygj+Ad4MBdY+c2YDYrHAd4J/+HpUYQxr1oTW h7pp2kKGl7if9etbiEc0We7pz+S9pF/+B5GoJcAl8RHsLZ2NOaIpldrPLs2hB0jP1i41 CMaA2jUyzbOfqiF1ZlH/ryKXRX0UFqaeyHTiGRCkASVrU35bOO5Aq0nel5SxuKZkxmnA ICBJxRrJGVHGbSaIKdH8lS+vF9dVtr4TPLWh+BpXKni3kTCrIDxe7ycnJh0kly+/20z+ jhOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743552849; x=1744157649; 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=YWQ2ocRDk8UrD/kB4KvMYAJSx6KLCBvwU+MsxS/somw=; b=Vm6zocD/FR4qW8fKLyHTZsM0nCMtE00ARLauD8F5X8ZkUzuzgV86rSLNu8BWi9Tojl /RDiWul9rleB83mUdGSQCORGhjFRKhYN1RohJowOiNtQD6WjZSwqq8DkJc8y6VbroPFb CVZppshsBj1ptkN/fWAaSyhf180cViAByVm5gSREwQVUM6KXP8Nsxo0gO/O7Fa3sGbFN qSGhLX6v336WRN1+tuihbTUJo37q5E7FSx7s+y8/CcFLFTi5vT7BegZdNeB/TKrmhkZg LGyB7Hnz5L08Jwsi2KVnd2t2RRjcd6EKw0z/5POdGhSpjUEECWRutm7YPsUz50+gJmW3 WBcQ== X-Forwarded-Encrypted: i=1; AJvYcCW8G+EJqdaSkE7y3Z8dO6UNxuO+j47yPOg66XuNvcNjEhOh2ny3y7DeVMzIWxdGvMbPSlCXHmK7gg==@kvack.org X-Gm-Message-State: AOJu0YzpWIZ+GZWoqhg0CE2mLaVTATBErJOPp069rIHDtW4pGYdvR1Xv kIQhGwxlx9ydiSOpuR4X8yxTnwGBQDeFXE7zTikIyKWBaCivVKv/OzsLVV4VS5xI3nhglhzjJFk 37FVDbvlpghajDNS3mM37y4JAErd64f4f7ml0 X-Gm-Gg: ASbGncuMAw1ThOihv+J/AIfh69ENcJO5ggkZtc+/6PbDXdjv8Qm9h9yZIuuT9WtDCjB g2O2My5+cN8poSu/iLlGgG9j4FZnkMr6lMi3rh9KUdfhT64CgrNjenZitB5gQ/UesA7+aT7r4Wv 6wp4CC0Mzv+6PpW5MMz3z3QICziSirBETWZ3HhycPVpBnWii16vt6HBebC X-Google-Smtp-Source: AGHT+IEUqL7Ad7UHvHVOv3GapJ3xChDN5disEmR7+cXyrIIUpmMtpqHpoY8RO6w1KCJS8RDCMRqp/5e+JG895uI72ow= X-Received: by 2002:a17:902:d4c7:b0:21f:2ded:bfc5 with SMTP id d9443c01a7336-22969e8c805mr1141365ad.28.1743552848066; Tue, 01 Apr 2025 17:14:08 -0700 (PDT) MIME-Version: 1.0 References: <3bd275ed-7951-4a55-9331-560981770d30@lucifer.local> <82fbe53b-98c4-4e55-9eeb-5a013596c4c6@lucifer.local> <2dcaa0a6-c20d-4e57-80df-b288d2faa58d@redhat.com> In-Reply-To: <2dcaa0a6-c20d-4e57-80df-b288d2faa58d@redhat.com> From: Kalesh Singh Date: Tue, 1 Apr 2025 17:13:56 -0700 X-Gm-Features: AQ5f1JoG3S88OyDppZMowOfF2yqfLMwf7guNr-qq6RU-u2QEU-UXuXyAW2GKDRs Message-ID: Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Optimizing Page Cache Readahead Behavior To: David Hildenbrand Cc: Matthew Wilcox , Dave Chinner , Lorenzo Stoakes , Jan Kara , lsf-pc@lists.linux-foundation.org, "open list:MEMORY MANAGEMENT" , linux-fsdevel , Suren Baghdasaryan , "Liam R. Howlett" , Juan Yescas , android-mm , 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: rspam09 X-Rspamd-Queue-Id: 338D71C000B X-Stat-Signature: dfz7d5wxuewetds6bgsc5yh6ekju7zce X-HE-Tag: 1743552849-211568 X-HE-Meta: U2FsdGVkX1+Sl7ElcHUyW6nkYSjtCfrzIJBcXGXFa75os387Qa6KHDUZJh45Zpsqp1O8uVxmp6xZAtLQPDyCpJ8y2j7NRhIuwaoNB90/V2Ai/zgNP0gSFItZCI6KY3v3O+DybYz05jFtS7EJJomY7+i8PFQS+1ImQNVAhBuRTemBnG0dTcZgfIWGgKx044J26IqM3SLfRirxHGydNPM1twKwFdEZ5PLH/AjLWKurGV2kEBafrp5Qjx0ReT1t5lW3gYoYXK8k3KuDFMt8SG96TAdZ+qTH/i33v1PO2RxvT1rkVW0yogewyirWCTnjuqzQ9i6RhsXRPzoN1ujYS0EBlaGb8RejISgKvwtkmg1tVHmLeH9a+BSIWxn0EPTy7YZqzodRhqD5DZZhdjmFmUrJExcG8pIG8AAB2lhaYGkHs4dz/yRMX8DbnPNApIkwUmBlZhq6aCg8UfGmRihxGE2a1A09hPUioCV29RhxhOPVP1ATLHmuP/jLcsKv6dZUMdtwxL6bejs9iO0mXkpBhPrHJxSXRDJxV6hPu2eFsI+fVdot4KuWjg05LdkDXzV/BEMGmPUzTvWa+suAIgOvv2kOCoAWwMbrSJAwm9nYCOJPE212uqqsDYBHQbNLetDC/adrrbePxnOVqUwMKDouqNnRG+nYiab19IRj7tw07ZVGoMWGAvW9d3R6PjOsh1t/NjPjVeYqcNhVD/ydzyiekjpqK+LUSpujdyc+wC8185q/fvnU3FQZN9kjiFWYPl2mTWAjrorSudPx470E4FVw0oE1JgzIRA4voLPmqVtZIpON/PUs7DFCFduB/wgZtgXGz3sojHa+3s+JYPpCnMTVfC8/sNqzKf1lthe3A6MhqenPCzg8WnjGa4q/t24Ts//g9g5mVU1QMdjsGpTdYTaDnVWxx4p8VqyJIJ1YhPoQ6Lr6jJqn48UbBZRqu7bSiW8cfDQozpGoql3Ejba+RUuhBmD nKHBGklM Jd1Xix9qRTyOLMnuinNgjwB50zfohBjeKisvrJJiyhiQ7zwP1UsUgm+t/bXkI+no2RLztLTUH8onZqejQNWmnGPFlirbMq+RUsNG+1R6vk/GSl+TZsT0pVJ8DrLQeN8+POUhK82QMQBrmVvaxRsIT92XVHW/Iu/dj2wwn00qLYz8hmIAFEcuDrRZbsjrDxjfviOQyr9Q7QHflQc8rXlgthK7weEcH6iUXAoAM1cV0LkC4hVKeGnzld+1o0tkkJii43lnepQK3cCa9Dd34mmeTu1J3RNM0NMgNKDfZZK6Dd8mQyEkga1dY5QiIesWUumcxppMr9hQGqgOzMx4= 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 Fri, Feb 28, 2025 at 1:07=E2=80=AFAM David Hildenbrand wrote: > > On 27.02.25 23:12, Matthew Wilcox wrote: > > On Tue, Feb 25, 2025 at 10:56:21AM +1100, Dave Chinner wrote: > >>> From the previous discussions that Matthew shared [7], it seems like > >>> Dave proposed an alternative to moving the extents to the VFS layer t= o > >>> 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.inf= radead.org/ > >>> [8] https://lore.kernel.org/linux-fsdevel/ZtAPsMcc3IC1VaAF@dread.disa= ster.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. > > > > Well, you shot that down when I started trying to flesh it out: > > https://lore.kernel.org/linux-fsdevel/Zs+2u3%2FUsoaUHuid@dread.disaster= .area/ > > > >> 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. > > > > The xarray is very much optimised for storing power-of-two sized & > > aligned objects. It makes no sense to try to track extents using the > > mapping tree. Now, if we abandon the radix tree for the maple tree, we > > could talk about storing zero extents in the same data structure. > > But that's a big change with potentially significant downsides. > > It's something I want to play with, but I'm a little busy right now. > > > >> 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. > > > > ... and unmap the zero page from any mappings. > > > >> 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. > > > > ... and unmap the zero page from any mappings. > > > > I'll add one detail for future reference; not sure about the priority > this should have, but it's one of these nasty corner cases that are not > the obvious to spot when having the shared zeropage in MAP_SHARED mapping= s: > > Currently, only FS-DAX makes use of the shared zeropage in "ordinary > MAP_SHARED" mappings. It doesn't use it for "holes" but for "logically > zero" pages, to avoid allocating disk blocks (-> translating to actual > DAX memory) on read-only access. > > There is one issue between gup(FOLL_LONGTERM | FOLL_PIN) and the shared > zeropage in MAP_SHARED mappings. It so far does not apply to fsdax, > because ... we don't support FOLL_LONGTERM for fsdax at all. > > I spelled out part of the issue in fce831c92092 ("mm/memory: cleanly > support zeropage in vm_insert_page*(), vm_map_pages*() and > vmf_insert_mixed()"). > > In general, the problem is that gup(FOLL_LONGTERM | FOLL_PIN) will have > to decide if it is okay to longterm-pin the shared zeropage in a > MAP_SHARED mapping (which might just be fine with a R/O file in some > cases?), and if not, it would have to trigger FAULT_FLAG_UNSHARE similar > to how we break COW in MAP_PRIVATE mappings (shared zeropage -> > anonymous folio). > > If gup(FOLL_LONGTERM | FOLL_PIN) would just always longterm-pin the > shared zeropage, and somebody else would end up triggering replacement > of the shared zeropage in the pagecache (e.g., write() to the file > offset, write access to the VMA that triggers a write fault etc.), you'd > get a disconnect between what the GUP user sees and what the pagecache > actually contains. > > The file system fault logic will have to be taught about > FAULT_FLAG_UNSHARE and handle it accordingly (e.g., allocate fill file > hole, allocate disk space, allocate an actual folio ...). > > Things like memfd_pin_folios() might require similar care -- that one in > particular should likely never return the shared zeropage. > > Likely gup(FOLL_LONGTERM | FOLL_PIN) users like RDMA or VFIO will be > able to trigger it. > > > Not using the shared zeropage but instead some "hole" PTE marker could > avoid this problem. Of course, not allowing for reading the shared > zeropage there, but maybe that's not strictly required? > Link to slides for the talk: https://drive.google.com/file/d/1MOJu5FZurV4XaCLrQhM9S5ubN7H_jEA8/view?usp= =3Ddrive_link Thanks, Kalesh > -- > Cheers, > > David / dhildenb >