From patchwork Fri Dec 20 15:47:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 13916931 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 C3301E77188 for ; Fri, 20 Dec 2024 15:48:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 082056B0082; Fri, 20 Dec 2024 10:48:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 030D66B0083; Fri, 20 Dec 2024 10:48:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E14226B0088; Fri, 20 Dec 2024 10:48:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C30626B0082 for ; Fri, 20 Dec 2024 10:48:39 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6D8BFC0B50 for ; Fri, 20 Dec 2024 15:48:39 +0000 (UTC) X-FDA: 82915769118.15.FE055A3 Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) by imf11.hostedemail.com (Postfix) with ESMTP id B8FAE40021 for ; Fri, 20 Dec 2024 15:48:04 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=fo5iQjeG; spf=pass (imf11.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.171 as permitted sender) smtp.mailfrom=axboe@kernel.dk; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734709700; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=5QLZfGQipkCBNguiWf4R+vP6AoBCDa/bCOHZx7IfU6M=; b=uu5bwephvONIjtaKVERsgcEGx9pVYk9TzkJgOHtGJQBXKuZEbsRTneOCeaeZ0ct41KT8Ji AjOMPmBx+ZXKWLagyfqcltUxj4C0FWgMaHftp7bpdcJa7gu5HX/udrXQIh14f557JPqE8r bMC7MGaCHjZeZSTLSGPI3a9wiMHqySE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=fo5iQjeG; spf=pass (imf11.hostedemail.com: domain of axboe@kernel.dk designates 209.85.166.171 as permitted sender) smtp.mailfrom=axboe@kernel.dk; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734709700; a=rsa-sha256; cv=none; b=6KLN4uxZrcrWEZ6LCNSt/2pZZ42zpqC5fOJg6ZtfpzaJsJ/1huM6D5iArHVp5nqjNNp+Nf SJQu4yYcxxe/zAwhm7r2Cf70EoYd077RzLqtV3/aBCMCACJ6cVGhdkN7xAwBcwZnsU52Ru chbmXnKNjnGx3nAUlMw/VIISDatvEwc= Received: by mail-il1-f171.google.com with SMTP id e9e14a558f8ab-3a7e108b491so15374705ab.3 for ; Fri, 20 Dec 2024 07:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1734709715; x=1735314515; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=5QLZfGQipkCBNguiWf4R+vP6AoBCDa/bCOHZx7IfU6M=; b=fo5iQjeG9ahNc4OsBdoV0GjDmYOegylFq0bsw3PHqGdn6CsVKpgXN5Yw1XCOmq9Mup /oDUsSdVySGj0CQ/stlOuC4ZGNhv4WE1Q4ubVBY10+m1Pj4ayMv328S4N0ZlDiC7Ns8F 3Ocd/nNh6ABIh5352dXQORk5BjPZf6WmUARdt4vi8frkr8HFv/jfTiFQcRo35VilGN3g xOwyCBdoELKALyNmpI0NvBfmM5a7ltM70VgZiDbBWQP1mrBZg8GwiWEt7OD1+YNEd46B vF82icTXBgcEwtxrAJU9k6QFMuOlSGefgKjF4UFDwTrPbIA13EENEMxXkjkOnAxhYH9K 7cLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734709715; x=1735314515; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5QLZfGQipkCBNguiWf4R+vP6AoBCDa/bCOHZx7IfU6M=; b=GfnZE9QeNnM2DD90fGWvw9/aSMzxtcH/4zMbNG5bw9JKQmLowPXlp8irpSpvNi3g6d gdnJXO/fXQTSGAFsFEFRisD0FGAM/WMccRt6eXeZogKTBCRyvKm/VZj5oSVXL4uFTJro 5+kEo617oZhqv9G+Xv7uNOpxnk+vdPbvJgpCVkeMfSSHJmyF3uy4sgxeOk1ug4sxsqgT J7Gdz9oghbr2OaClbdUx+yN3/K6izBJVbxjVJTInuNsHMXT4H681+gfk4dBCPxG/xwLE CGlGz0vOvBuWH07Vuq6otbsZ6p3Jaji0apS7L+tkU5SF99Y7/gJHPulmZh6jHuxkAwiZ h5xw== X-Gm-Message-State: AOJu0YzFIQELI5QzplvNsg1en9PpLFBmIrFVbd7xPAWd6LJt7hGuJV46 sPW54am8DJ4zDhlXg3sPl/6uUJ4EVbSd1sERvcZtKzSIdqwyiItnDvT07nHunMD52hPcJXPCd5N y X-Gm-Gg: ASbGncvKnLXSEwgU3sNiLuFaWYP4FKildvoErWXTvbe4yemdu1CqN5QSIT3tMAlSqay B7EOj/96C/8Crzcx5TjZFz09E2BRZqVYbbVT6iUE+QfoFD7rb120EV05LnzAEOvilFEEy7un5gT l2RSAi0kbEKfFDF8DgomsCt42rzCn6aECjriXG5xSrhEWz/QrtuveIHdBICYFuiX8kHEDW3DyeY UhD3AhUD/P8nYhNl43VSq8vJ/Ur8eSB0Sm6dlquEwNhQ7jYQNax9vn7442X X-Google-Smtp-Source: AGHT+IFEaCG9dI5jmaOPYYr5r7MTJolx0zr+xkp1PBAQcFRP+7qgC9EarkW8EUqWjETP8fYqrkS6Wg== X-Received: by 2002:a05:6e02:19cc:b0:3a7:6e97:9877 with SMTP id e9e14a558f8ab-3c2d5a27dd7mr35198935ab.24.1734709714725; Fri, 20 Dec 2024 07:48:34 -0800 (PST) Received: from localhost.localdomain ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4e68bf66ed9sm837821173.45.2024.12.20.07.48.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Dec 2024 07:48:34 -0800 (PST) From: Jens Axboe To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Cc: hannes@cmpxchg.org, clm@meta.com, linux-kernel@vger.kernel.org, willy@infradead.org, kirill@shutemov.name, bfoster@redhat.com Subject: [PATCHSET v8 0/12] Uncached buffered IO Date: Fri, 20 Dec 2024 08:47:38 -0700 Message-ID: <20241220154831.1086649-1-axboe@kernel.dk> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 X-Rspamd-Queue-Id: B8FAE40021 X-Stat-Signature: fdh8um918u9u3mugu45tkhwca4osujuk X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1734709684-807841 X-HE-Meta: U2FsdGVkX1/EdQI8Wfbwspe6Es5pgeH2bfOsPjZH/PNfWrVpupRk9VwuzLe3ZM+eXnkl6owoVtBQmGYzg1aIEstZQLvURfmogiAKyUdw4OvO/EIexwLt4I+m3RyvERUElvQZy0FE9TV3AGc0ljjJFu5OPDlaa0WGUXmmcl0FoRyUMQhsmdK5B+DNrbYMcc04WJ/+4OsI+G2P4UJQk14Un6hBUROn1ibsbKXDMQ1ZVx3cURKDn1u8B2W7uV9ZsHAMGYj1ndLYVotviKWeXZWNvEV/3gEC/isq29mWj3vEQivaYy6+0XjOSTY0spBorBxn6HZg0WFd8DDpq/kKVUE8ZWvKzxzdkA0vNKtME1B/Mh6ttC+KFsBBTKbeNQNAAohtQ1BngDjIysTbB+K52ySidgYm76ajDJaJYcpEXj081t2FtUi0qKSxMuJazT+jeBXLUZFkE1M33Dwz3a0t25pFc1YBA7EaKpwUKxSZGBjHPGoOVOWLye5M1flBBC4nt20noOFqQP3caFrremSo5XRKBQjOQM3fLVNdZN+G8A0NTviuJ2xciVnS0oQdKFL4zvKw0svn591+/uYjUolC5F+vC98mV4tbEPoVnnckOI4np3iUdoxLEFRTNAE5jr/HKwNOKYjFS7/brJzJZss42k6qwemYj/UZ26RgNWHTAkXIobpiqtqK4j399QopUEmS1j2GgsKMLMuQd8JR3c3aPG8E2762P+sbSEuABUlU94J2aEPA01hIcx4wlLm+mVsQueh7/IuwIna1tO+aw62ZFVmFtpIEx1wtoaG4bkad9XsGav+iAxgtY3hG3yssBFB2oAFJ3gfTi+8twnrnXUrg8eKTFmbmy4hHm2PQyan5xr2eSxqf5Ya99EGauifLFVvj1hWI331z6YPq6lCdwENjSArX9ZH27I3yuMjM/wxQnIYbac5JnM9mDfdoGNtFtyT06lbG8bpuw6rTZK0RxgCvRmg GhPjiqTF jYqU5bLeACg1LmAeJx4SkSeTtcvoPDeONBIRLRInKo38mGjrYJPQ1u/7QQEchm42jdLgkox3oqp56mGs+k7lPONx45JFYQtsTaU80Gg1I7Gxxhtno0pzQO56geo4mua1BBl4Lh9cf20gZQlOKbo8VO/W6PVmPItjaRzb17zuJM4jZTslyeGhjwMKSp37v3Yo3U7sGo6Dm5Qk216nQbdy13zbQO8RSDyuccuceorgr2H073AvfA4kXhxN7kYkMws4BI9ifua5IpSj9ed14W8I3ktmBei65ndAGdGD/A+km5oCVid2FCVwBlE/dPgPRJjdv94U9ClWh+4dGSFuiwMxPNJu+YfYUgb1DsbPIlQkx18151CQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, 5 years ago I posted patches adding support for RWF_UNCACHED, as a way to do buffered IO that isn't page cache persistent. The approach back then was to have private pages for IO, and then get rid of them once IO was done. But that then runs into all the issues that O_DIRECT has, in terms of synchronizing with the page cache. So here's a new approach to the same concent, but using the page cache as synchronization. Due to excessive bike shedding on the naming, this is now named RWF_DONTCACHE, and is less special in that it's just page cache IO, except it prunes the ranges once IO is completed. Why do this, you may ask? The tldr is that device speeds are only getting faster, while reclaim is not. Doing normal buffered IO can be very unpredictable, and suck up a lot of resources on the reclaim side. This leads people to use O_DIRECT as a work-around, which has its own set of restrictions in terms of size, offset, and length of IO. It's also inherently synchronous, and now you need async IO as well. While the latter isn't necessarily a big problem as we have good options available there, it also should not be a requirement when all you want to do is read or write some data without caching. Even on desktop type systems, a normal NVMe device can fill the entire page cache in seconds. On the big system I used for testing, there's a lot more RAM, but also a lot more devices. As can be seen in some of the results in the following patches, you can still fill RAM in seconds even when there's 1TB of it. Hence this problem isn't solely a "big hyperscaler system" issue, it's common across the board. Common for both reads and writes with RWF_DONTCACHE is that they use the page cache for IO. Reads work just like a normal buffered read would, with the only exception being that the touched ranges will get pruned after data has been copied. For writes, the ranges will get writeback kicked off before the syscall returns, and then writeback completion will prune the range. Hence writes aren't synchronous, and it's easy to pipeline writes using RWF_DONTCACHE. Folios that aren't instantiated by RWF_DONTCACHE IO are left untouched. This means you that uncached IO will take advantage of the page cache for uptodate data, but not leave anything it instantiated/created in cache. File systems need to support this. This patchset adds support for the generic read path, which covers file systems like ext4. Patches exist to add support for iomap/XFS and btrfs as well, which sit on top of this series. If RWF_DONTCACHE IO is attempted on a file system that doesn't support it, -EOPNOTSUPP is returned. Hence the user can rely on it either working as designed, or flagging and error if that's not the case. The intent here is to give the application a sensible fallback path - eg, it may fall back to O_DIRECT if appropriate, or just live with the fact that uncached IO isn't available and do normal buffered IO. Adding "support" to other file systems should be trivial, most of the time just a one-liner adding FOP_DONTCACHE to the fop_flags in the file_operations struct, if the file system is using either iomap or the generic filemap helpers for reading and writing. Performance results are in patch 8 for reads, and you can find the write side results in the XFS patch adding support for DONTCACHE writes for XFS: https://git.kernel.dk/cgit/linux/commit/?h=buffered-uncached-fs.10&id=257e92de795fdff7d7e256501e024fac6da6a7f4 with the tldr being that I see about a 65% improvement in performance for both, with fully predictable IO times. CPU reduction is substantial as well, with no kswapd activity at all for reclaim when using uncached IO. Using it from applications is trivial - just set RWF_DONTCACHE for the read or write, using pwritev2(2) or preadv2(2). For io_uring, same thing, just set RWF_DONTCACHE in sqe->rw_flags for a buffered read/write operation. And that's it. Patches 1..7 are just prep patches, and should have no functional changes at all. Patch 8 adds support for the filemap path for RWF_DONTCACHE reads, and patches 9..12 are just prep patches for supporting the write side of uncached writes. In the below mentioned branch, there are then patches to adopt uncached reads and writes for xfs, btrfs, and ext4. The latter currently relies on bit of a hack for passing whether this is an uncached write or not through ->write_begin(), which can hopefully go away once ext4 adopts iomap for buffered writes. I say this is a hack as it's not the prettiest way to do it, however it is fully solid and will work just fine. Passes full xfstests and fsx overnight runs, no issues observed. That includes the vm running the testing also using RWF_DONTCACHE on the host. I'll post fsstress and fsx patches for RWF_DONTCACHE separately. As far as I'm concerned, no further work needs doing here. And git tree for the patches is here: https://git.kernel.dk/cgit/linux/log/?h=buffered-uncached.10 with the file system patches on top adding support for xfs/btrfs/ext4 here: https://git.kernel.dk/cgit/linux/log/?h=buffered-uncached-fs.10 include/linux/fs.h | 21 ++++++- include/linux/page-flags.h | 5 ++ include/linux/pagemap.h | 3 + include/trace/events/mmflags.h | 3 +- include/uapi/linux/fs.h | 6 +- mm/filemap.c | 102 ++++++++++++++++++++++++++++----- mm/internal.h | 2 + mm/readahead.c | 22 +++++-- mm/swap.c | 2 + mm/truncate.c | 53 +++++++++-------- 10 files changed, 173 insertions(+), 46 deletions(-) Since v7 - Rename filemap_uncached_read() to filemap_end_dropbehind_read() - Rename folio_end_dropbehind() to folio_end_dropbehind_write() - Make the "mm: add FGP_DONTCACHE folio creation flag" patch part of the base patches series, to avoid dependencies with btrfs/xfs/iomap - Remove now dead IOMAP_F_DONTCACHE define and setting on xfs/iomap - Re-instate mistakenly deleted VM_BUG_ON_FOLIO() in invalidate_inode_pages2_range() - Add reviewed-by's - Add separate fs patch branch that sits on top of the core branch - Rebase on current -git master