From patchwork Wed Dec 18 17:16:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Snitzer X-Patchwork-Id: 13913990 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 E3F47E77187 for ; Wed, 18 Dec 2024 17:16:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FD6A6B008A; Wed, 18 Dec 2024 12:16:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AD846B008C; Wed, 18 Dec 2024 12:16:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39B936B0092; Wed, 18 Dec 2024 12:16:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1CE7A6B008A for ; Wed, 18 Dec 2024 12:16:50 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8354F121010 for ; Wed, 18 Dec 2024 17:16:49 +0000 (UTC) X-FDA: 82908732648.09.BC19984 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 390541C0003 for ; Wed, 18 Dec 2024 17:16:14 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LaRZII0X; spf=pass (imf20.hostedemail.com: domain of snitzer@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=snitzer@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734542174; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=uBoR0fgK4PND4WTMh9DAMhevhjtZmDOLYiPdk2hjIsQ=; b=MiUR+3fcEPwcqQdPaDidCoqZaLtyblia+Do4c3e3w94Dh6p/+u9l3GtIWKvNDCZUo3feW/ j13bWMrpAixgbQ2M1zcvW7v4p/2pDIUs6Vq0MYiE9kTjSMBdH4V7+iBd4ds5svMjZURowb xDybGN4mQe+6/xer62AL0PhHN0OSkpc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LaRZII0X; spf=pass (imf20.hostedemail.com: domain of snitzer@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=snitzer@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734542174; a=rsa-sha256; cv=none; b=0x5PU2GjsiaRDlch+ZfcNBl8Uq0rJjMPPZtl8X1dDBtg7VxPQ267ynV6sewo7l7mQfbBzb USZ4jdZyxnocFcGGKUslNdb2mz5hHl4isZ0NmS8F+8qRyxl7MM9AQbGefyNoDdsjHe5M2D dclfT2UfFhNebo4zS9tSYaog5Txb+g8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 6387E5C63D4; Wed, 18 Dec 2024 17:16:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4C71C4CECD; Wed, 18 Dec 2024 17:16:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734542206; bh=vByKvfBxoRz2Ew61HCzPzSOCqlcnxTOUTykzOp1/1ME=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LaRZII0XV6az6sQ50USic51NDQt/fhWVoYaA0YSNVF8wUYpBxoJhSrjQCGTK6ajMD z44k3r2auvUrUCAQ2utziWzufJqHMxWXuyjupFw2hQDT4GtknGMBDIwv/yAYqbujzO 30CCkreSlXnX7bEvuNiMcv3X/KgZCvjfJ92T2tLmULVlTdo4UJ4eE8TL+mLSttbx8p 9mc3PfIVjxlmEs4uz9KMwzQaubt0ZtM0FbNMIwtm4XvZDZ0iIKywCsSTvbpiYkh8K8 ZMAkejSDmtJ60gpcz3HHFd7QMoSicq1hWSYwaIKB9HXHte41/NmPr73vJCAMZ5698y t9dJEp6sKqvDg== Date: Wed, 18 Dec 2024 12:16:44 -0500 From: Mike Snitzer To: Jens Axboe Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hannes@cmpxchg.org, clm@meta.com, linux-kernel@vger.kernel.org, willy@infradead.org, kirill@shutemov.name, bfoster@redhat.com, linux-nfs@vger.kernel.org Subject: [PATCH] nfs: flag as supporting FOP_DONTCACHE Message-ID: References: <20241213155557.105419-1-axboe@kernel.dk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20241213155557.105419-1-axboe@kernel.dk> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 390541C0003 X-Rspam-User: X-Stat-Signature: rf9oamys8hyks5wmd7igxxbkdsz1xu66 X-HE-Tag: 1734542174-448501 X-HE-Meta: U2FsdGVkX18vzd/GjUSwvkPMb/V9n7dyFpMHQjoStvjPmjv4n7A8V3l3eOjvrQboQkJC58jIpFkkTG0JHzcDrPLjQi/ftr4tQBElebk+dzqRmyOGkjgqY4jqzkMwxWVTqbm9LCg4RPWJVHWdm+/MjBtZ5KRnRf8/VlHt/Zr2RBrs8JfZL/fAT+Jde5+T08kz67CKbnzaq2Jc1MJbC/KFHs7Y7/BKWOlGQkRV0Ituy2MqfpB28xY/UD17M4BdClwUdyAtDlDOkcsQsfNpiIDIgWNz5wUlnNvbdAwSS5hKTaGDSscwPyjr0sdpUGalNZmh/gW94HKFl0hvGHmcostbM2izg6xP4e2NhfLUlgEJ5CCUXS3CmgXR64xyRvXF3b7tsD9HQjpMguO+qwblSgFGNZszEJp0rRIJrkAoQcPSirp4w8i8TRNpqjxpXhdAbFQRon0HH4NbgHzVGFCsVsGhUSaY2ENc9LyRCqF/k/I10qTbY/LyNL7t9KghlN5p177bdrsxLWoUv/XanI7uycs5g4EefQKUi/hI9/mgwXHVQ/otKzcO7iJ41a5Da5nx/zqN9Qgb2y4/7Ckg45t5mCp8zCub0mcm0npPPFGEje0GksIbTyxAkebNq/3sk5Z/T54dQ3r9Ee+9c6I/8Tgg5yXj9+0ZRQQbeLE2sLRuzGORT9CrdQvTqC4jsNWskcWPP34BKzCfMFSSX6h21jrIBJrjWh7ByIthW3nhDq96tW484cgPYvuA2k239rLgReW7CVtwOdizJJxx/7de8M/ZgiWESZd3hlksITEZ65myzMD2YlfHwUS8mxzaHzFdAf2gzsYv1+Re4dZQijLaLIogvX5Hyq88gCpump7Do9up+SMYQCbTugnJYAUyHMpImFkIbiUv9eqd48N6ZM130Qmobu/P83zcboYpvOQJqCZm7YWEPa04gl5vMOR2PpaD8Z9t8Qbr+fZwQ96gXQrSySHhFtd kNtuWUTG Ix3A+oASJbiS/MOKorRGg126MtmxIUntUvcD+xnnfQ1K2FDwujC0MCyZU1fccnzm7j4UOEOGhehgSqcQbGD/d3PJuJ8JRDHtmXOjrkE98LDMRULzJPU4zrrRVx5IxY+KFEz5aXDXdoU1dmP07Cj9UXdi0iAva5ca7fNS/Soc78S4InTZDP9Zu0h9klqtuT2dJV6nA8LEYRTmalsYXW4QsRNhgNT3TgE9RFJTVncdXVJ44IsChERV18tukwGiI60Me89pBuPCDyFJ2fNa9XslQwD5XIZwBoipBHaf868fJQcgxUTfrUYwgiLrwO7rAc9+FhdJDlAMKSYtoO1nvPZP6xEyuvWZbtMce36csYvSN2M+r4/WSZlAVaylJY0LzNWapBwaxbTFbGzt8Bg6s9gdCrvndlxH34VUIV3Qd2ALwrHC9yrra+GVVI6etnQ== 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, Dec 13, 2024 at 08:55:14AM -0700, Jens Axboe wrote: > 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. > > 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: > > ://git.kernel.dk/cgit/linux/commit/?h=buffered-uncached.9&id=edd7b1c910c5251941c6ba179f44b4c81a089019 > > 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..11 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.9 > > include/linux/fs.h | 21 +++++++- > include/linux/page-flags.h | 5 ++ > include/linux/pagemap.h | 1 + > include/trace/events/mmflags.h | 3 +- > include/uapi/linux/fs.h | 6 ++- > mm/filemap.c | 97 +++++++++++++++++++++++++++++----- > mm/internal.h | 2 + > mm/readahead.c | 22 ++++++-- > mm/swap.c | 2 + > mm/truncate.c | 54 ++++++++++--------- > 10 files changed, 166 insertions(+), 47 deletions(-) > > Since v6 > - Rename the PG_uncached flag to PG_dropbehind > - Shuffle patches around a bit, most notably so the foliop_uncached > patch goes with the ext4 support > - Get rid of foliop_uncached hack for btrfs (Christoph) > - Get rid of passing in struct address_space to filemap_create_folio() > - Inline invalidate_complete_folio2() in folio_unmap_invalidate() rather > than keep it as a separate helper > - Rebase on top of current master > > -- > Jens Axboe > > Hi Jens, You may recall I tested NFS to work with UNCACHED (now DONTCACHE). I've rebased the required small changes, feel free to append this to your series if you like. More work is needed to inform knfsd to selectively use DONTCACHE, but that will require more effort and coordination amongst the NFS kernel team. From: Mike Snitzer Date: Thu, 14 Nov 2024 22:09:01 +0000 Subject: [PATCH] nfs: flag as supporting FOP_DONTCACHE Jens says: "nfs just uses generic_file_read_iter(), so read side is fine with the flag added and generic_perform_write() for the write side, wrapped in some nfs jazz. So you can probably just set the flag and be done with it." Must also update nfs_write_begin() to set FGP_DONTCACHE in fgp flags passed to __filemap_get_folio(). Suggested-by: Jens Axboe Signed-off-by: Mike Snitzer --- fs/nfs/file.c | 3 +++ fs/nfs/nfs4file.c | 1 + 2 files changed, 4 insertions(+) diff --git a/fs/nfs/file.c b/fs/nfs/file.c index 1bb646752e466..ff5d4c97df494 100644 --- a/fs/nfs/file.c +++ b/fs/nfs/file.c @@ -354,6 +354,8 @@ static int nfs_write_begin(struct file *file, struct address_space *mapping, file, mapping->host->i_ino, len, (long long) pos); fgp |= fgf_set_order(len); + if (foliop_is_dropbehind(foliop)) + fgp |= FGP_DONTCACHE; start: folio = __filemap_get_folio(mapping, pos >> PAGE_SHIFT, fgp, mapping_gfp_mask(mapping)); @@ -909,5 +911,6 @@ const struct file_operations nfs_file_operations = { .splice_write = iter_file_splice_write, .check_flags = nfs_check_flags, .setlease = simple_nosetlease, + .fop_flags = FOP_DONTCACHE, }; EXPORT_SYMBOL_GPL(nfs_file_operations); diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c index 1cd9652f3c280..83e2467b7c66f 100644 --- a/fs/nfs/nfs4file.c +++ b/fs/nfs/nfs4file.c @@ -467,4 +467,5 @@ const struct file_operations nfs4_file_operations = { #else .llseek = nfs_file_llseek, #endif + .fop_flags = FOP_DONTCACHE, };