From patchwork Tue Dec 3 15:31:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 13892617 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 061BFE64ABB for ; Tue, 3 Dec 2024 15:32:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94AE46B0083; Tue, 3 Dec 2024 10:32:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FBD36B0085; Tue, 3 Dec 2024 10:32:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79D126B0088; Tue, 3 Dec 2024 10:32:49 -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 57E3C6B0083 for ; Tue, 3 Dec 2024 10:32:49 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 15560A0ADD for ; Tue, 3 Dec 2024 15:32:49 +0000 (UTC) X-FDA: 82854039912.06.DCE06FA Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by imf18.hostedemail.com (Postfix) with ESMTP id 165BF1C000D for ; Tue, 3 Dec 2024 15:32:40 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=QHBEtSTf; spf=pass (imf18.hostedemail.com: domain of axboe@kernel.dk designates 209.85.167.179 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=1733239952; 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=2HZHG8qEfkcKm6/83F+woZUDdj6/tbhXxaseTSsadHk=; b=Na3noLdBEQ81S9ek3m+WQPtD4sizqR7IAvyy+6X1z/Kq0DzimUYQNrlvbO69pXhkyv7qwY abEzuE3fnSn1ySNozQNPyKSC54PsGToKT+w40ltUaynCfTy5T4V/+ny6GAmyHRBG3ROrgI gkJlNHIPWKicsHXQGDoTlwZwidh4SJY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=QHBEtSTf; spf=pass (imf18.hostedemail.com: domain of axboe@kernel.dk designates 209.85.167.179 as permitted sender) smtp.mailfrom=axboe@kernel.dk; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733239952; a=rsa-sha256; cv=none; b=yPuCz9eID5WIL1rKMROwsopSzXrPmYw3WFeLbXIhfZYfKcZc1XR+AazR8PEhS1k8c/kdyI wNkLWcmzXRk/evH8ZQuAaM1qABznoJ5RhE6k3jXwItj1kW7eZrpVTuIPEl2nIE1w+YFEEE /j/00DtvNJ72BIWjJ+Sz4+qYAAix8C4= Received: by mail-oi1-f179.google.com with SMTP id 5614622812f47-3ea3cc9a5ddso2807944b6e.3 for ; Tue, 03 Dec 2024 07:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1733239965; x=1733844765; 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=2HZHG8qEfkcKm6/83F+woZUDdj6/tbhXxaseTSsadHk=; b=QHBEtSTfQrBAV/6rqnU8ptg8pQI0oAWZwnPuS015ZXo0PxjesO3U5iIke+ATe3yDV2 QDx/GU2Vi9J07RHS5A3Q3H8+HeCbqoUUz2dCQEFRji9JyEsPdzbytRJC7rsiIrPaSoFh 3zOefZ7IcLu/ERfgd1oq4wrhjm25R8chHs/wHnpJIlmuHCdGEZrsPeXoUFE+958zswOG x3KeqXg+Aq5ZKtH1ZCgkZDy/yDX2zRqMTVBXKRGKk6v4mRW9hzx8mH/3O78v1SAUuPig ULRl9TpVIslaTjcUBrUKZlKBIDF7pMlFANiLB6iALAnMsvn93aMso4ayoMRDv2SER0jA yFzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733239965; x=1733844765; 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=2HZHG8qEfkcKm6/83F+woZUDdj6/tbhXxaseTSsadHk=; b=Neq08AvFHHzN9WV9n8HSxf4S6X/phCuJi1n8xKwHIMuOOz7ZNZ4LPfJIGLROJq/dVD vNzFl2/4MfRiPZhe5qLnFA6opZoq3xRdRNxj5V7UrChst5BLHUNx5VF7nDpVDVaTI5ia NUxd2dsgnZBQkH4DCkx4Lu/J/wPMjT4VDd1XL4swN7rwYXGIdsELsOTyJYi3q5eArEww HKH9gZUQu1sDTzwx3GZbgU3uGgiRi2/9okjSJDFuiw8EMpakwgOsmg1pnB3rGla7tDH3 8yMVjnduQziY8cdC48w1Z7lm4Z8rFacLm4F/Q+bA4mKs4ub7LRq4WBmu2lGVrtyWNtAU PHBA== X-Gm-Message-State: AOJu0Yw9IfJ6W9Ey118/Y1oX8iw62FeOhLwwet0QOzFsGvEwl8LOKv6y ldY3xxlEr/Imr4veFnKPwBKGam1w8BO7KRZrzovRpuhm5qO8W+g4WUP9AlVjkjAvAY+gKYYkgdh V X-Gm-Gg: ASbGnct6oR7Ko3yICdaYPWhBeQmJIVQQ1/Q0nO1cN3zWPPhxrZrOkFDZLg01PUrnyLY 8/VOsbgKcnRnDJYAxoAEbQVMmKCDocb88Qv4ilviuAmn7WtRGjYaE2VOJM0LUmcavo6DAE2JOgu Xmxsic1rD/9gT/gFW1QPjD6zQIaTufSWwpyeE0GmHCIsof6rupnvCpGyICxDL1UkbY80yCBWMDm r+ohkwaKEh+0dvTVLVqFMZSV3d/e3O+QL03ydAdZ4NoGNb9J/qxb62deWA= X-Google-Smtp-Source: AGHT+IF3bKaCVeTwKmpj/Uuop61+2KuNOAf8A7q4MCbfYKhXZErIYLFEKdETPqvJNmapDAl+Xet+UQ== X-Received: by 2002:a05:6808:3092:b0:3ea:6149:d6ef with SMTP id 5614622812f47-3eae4edae8bmr2905608b6e.1.1733239965326; Tue, 03 Dec 2024 07:32:45 -0800 (PST) Received: from localhost.localdomain ([130.250.255.163]) by smtp.gmail.com with ESMTPSA id 5614622812f47-3ea86036cbbsm2891878b6e.8.2024.12.03.07.32.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Dec 2024 07:32:44 -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 v6 0/12] Uncached buffered IO Date: Tue, 3 Dec 2024 08:31:36 -0700 Message-ID: <20241203153232.92224-2-axboe@kernel.dk> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 165BF1C000D X-Rspam-User: X-Stat-Signature: mao4xu7nc6bbhtym9mefc8i3tbk7a8c1 X-HE-Tag: 1733239960-211162 X-HE-Meta: U2FsdGVkX19J9VIJ3BRLsTOcgGWMUjJEONpcJZIDbAdk4BTvZa0YgsDZttoU167pxP+z/c8LqhgeboP/u+w7d2Wes7x2Rwp9LVu9t6o76cOPtVc2RiKYYzCazk0nhrkoa1InFDH9k0vhhykK7TqE6seGMSK8tsUZkah0m5haPIAbBvFhawztYHRjOqiIHi9emEVE1CLj8uOPYWUtJ2vIKd8kcVvxJU+k8bAjge56+/XwgZtA9cExI1YPSWl3BdxPVs2FnefkAB37rCy7HhwCF+HrJHVhWSiA/SNRA4d636g4eYooDcrpt3KSTvhKcE2I+L5HgUDb/J/kVvW69YXbjhBrq6pKybDc1fNe6evCEZNKNUAEWXyfvdB0gYsfu0EMZ5hbJq8Off2COyScrCEON/ifUGKjDdTuk2ncPqaiE+CcqcdrA3HtnERDy4PnHQUJ1XtQVZ7rd1X5x2jvRfF8hUZSuZCieqHSwAMwsb06qIxN4Q+4adabqlC0jG1AocaA90RlRM+79G/gFvypgYXpWVErnXHSYfdgMiSAnDtjuqBy9GynXTq9v3viv7NEyTlFkz1e+a/EfD2bZA/II2e0a3264jlkOJkaYJUlBSY/aSiG2GojPNxZ43g3MNkqMtRuy9lKzpDwfBmRNxtVTncM9aFn6nQxKyIw/GV1lTRRy/iPDzFNavfggbY0xzjTPmzuE4xp4T5gp+2tD2wNZ8YW3LfPuKu7+LhGUJ3jrLhy5KRN5cJ/GFbKIGms/AYtk/lo6DXLJLUgozM44cK7u+ftPFzAvCyE9WsdG+WK5NKwuexCMlcbLQdUG5Z+tLZEGYARqPfgUlRRV2d6b2p73sRwf+x9lFUWdaSPZVlmfLBXzCt0wdp0khlDcqWB/rxidrIniBWln1p8NAAupAcmm0BNfnUKGsbz47yZAYgSxBHNC0MF+ZEX9VFJocSCbG9q923BuCoioTc97S9kVsy9Nc4 QdMXL0Om 7IMxJdTUK0EykxBFB6Di/zp01VpFKuGoF6nM+5NY7UwJPK2avQd0176BqB8XaumEnY14+bipXkCus2NdHJmCiPWaSnfy/C8Hlw+/3JR+YV4/bhj0b+2brxAHNV4cWU6MK/4i4/Nz5t2jffqW3kqDnDAZeAnVv4FgYdQtN9nvQIrC1ESWMsvSPQwx9/KNNtGxyCZwouyz+DIa/4+AikXu3LFmvS/rbK0b5ZX4tDFC1rHnPBGtvMJ/E63l278Nz+gJlIr9clV72LjMl4/VJvHvXACpXmCgtzJ3M++O/8vpUdIu9Xu96vLsKnq4imVvYcYd0zOEClsfsmi5nc9WMIe+J04hR0xNWOC3L7dcmccutjn4EWlU= 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: 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. That makes RWF_UNCACHED 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_UNCACHED 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_UNCACHED. Folios that aren't instantiated by RWF_UNCACHED 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. The patches add support for the generic filemap helpers, and for iomap. Then ext4 and XFS are marked as supporting it. The last patch adds support for btrfs as well, lightly tested. The read side is already done by filemap, only the write side needs a bit of help. The amount of code here is really trivial, and the only reason the fs opt-in is necessary is to have an RWF_UNCACHED IO return -EOPNOTSUPP just in case the fs doesn't use either the generic paths or iomap. Adding "support" to other file systems should be trivial, most of the time just a one-liner adding FOP_UNCACHED to the fop_flags in the file_operations struct. Performance results are in patch 8 for reads and patch 10 for writes, 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_UNCACHED for the read or write, using pwritev2(2) or preadv2(2). For io_uring, same thing, just set RWF_UNCACHED 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_UNCACHED reads, patch 11 adds support for filemap RWF_UNCACHED writes. In the below mentioned branch, there are then patches to adopt uncached reads and writes for ext4, xfs, and btrfs. Passes full xfstests and fsx overnight runs, no issues observed. That includes the vm running the testing also using RWF_UNCACHED on the host. I'll post fsstress and fsx patches for RWF_UNCACHED 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.8 include/linux/fs.h | 21 +++++- include/linux/page-flags.h | 5 ++ include/linux/pagemap.h | 14 ++++ include/trace/events/mmflags.h | 3 +- include/uapi/linux/fs.h | 6 +- mm/filemap.c | 114 +++++++++++++++++++++++++++++---- mm/readahead.c | 22 +++++-- mm/swap.c | 2 + mm/truncate.c | 35 ++++++---- 9 files changed, 187 insertions(+), 35 deletions(-) Since v5 - Skip invalidation in filemap_uncached_read() if the folio is dirty as well, retaining the uncached setting for later cleaning to do the actual invalidation. - Use the same trylock approach in read invalidation as the writeback invalidation does. - Swap order of patches 10 and 11 to fix a bisection issue. - Split core mm changes and fs series patches. Once the generic side has been approved, I'll send out the fs series separately. - Rebase on 6.13-rc1 Acked-by: "Darrick J. Wong"