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 E5355E77173 for ; Fri, 6 Dec 2024 17:17:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F4FD6B02AE; Fri, 6 Dec 2024 12:17:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A59C6B02AF; Fri, 6 Dec 2024 12:17:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 56CAC6B02B0; Fri, 6 Dec 2024 12:17:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3A9036B02AE for ; Fri, 6 Dec 2024 12:17:44 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DDCA21A1C27 for ; Fri, 6 Dec 2024 17:17:43 +0000 (UTC) X-FDA: 82865190912.04.3E155C2 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf25.hostedemail.com (Postfix) with ESMTP id E6FA2A0013 for ; Fri, 6 Dec 2024 17:17:29 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HKgt2+7P; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.hostedemail.com: domain of djwong@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=djwong@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733505454; 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=gZdRh87rQ+9jFsX8LE7mIEWJRNrSZUwGabK7NcFCjR4=; b=mwOlzYmxf88Ui8J41o9Qz8gtXpXG2MxSfObbYpazymKp1suUy0Avrj7V5h3ukM5UYbV/an 851zzBfOpqozbgENcZW0/zR2SfiBq486ejRLp5GR/pjWQwEZmPr1D328m5vBsszha7sWYu Q29jdOHRO46r748aYi3s4PO2y9u1D9c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733505454; a=rsa-sha256; cv=none; b=DGfDzEGm5oW5mmPHk1pRxsAP8zJTckmdfLwA4bgH44ZE8OSO5DkdTq/FPa8kDEKicxEwJZ yZTJK14POVcXbZWl8TUbKTqLEFs+us6YQzrnobJCqptTFWe8Bm7b/rDkdton/f9hmt5lat 6FPmp5nITUbQNf1NyVxvAV+Vka6T+38= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HKgt2+7P; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf25.hostedemail.com: domain of djwong@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=djwong@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 82F10A43E74; Fri, 6 Dec 2024 17:15:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15F30C4CEDC; Fri, 6 Dec 2024 17:17:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733505461; bh=AuFd9Gw9Dc3IjuRANbTBGi5vZ1aTaRD1b70Nt5M3/Gk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HKgt2+7PsmXp/c3SLX5DRDO4UKmcDueQlB6L8vcYDbkTVx6oxX6sdsOVjWa74rYUc BhJQgqOH9plH5nYy/Hf3ZTUYhIjBtd2RRBIkfcuD/Sl5sefeL049ABTLUDiW/TeLG8 4ntM6J8akUAuppFLoFuLF+WlUgGXFhRU48p7jkskoPe4E4e7+NDZvzrgVVNgpwjSZL 0xXGRimCLcOT1cgnbyrj8jri90dMOmkry36F564cOGqUNmERGzswBng49Ut0xl0Tg8 mpgBsgKMYd4/U80vYNYbYFezO7D6yK+wrEBWrUVowxwA82RmE/r1bvGG6+aaATpQjo +hVc9EFOIkXOQ== Date: Fri, 6 Dec 2024 09:17:40 -0800 From: "Darrick J. Wong" 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 Subject: Re: [PATCH 11/12] mm/filemap: make buffered writes work with RWF_UNCACHED Message-ID: <20241206171740.GD7820@frogsfrogsfrogs> References: <20241203153232.92224-2-axboe@kernel.dk> <20241203153232.92224-13-axboe@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241203153232.92224-13-axboe@kernel.dk> X-Stat-Signature: s7nxmxo91pykokczbobd5zwintkf3mq6 X-Rspamd-Queue-Id: E6FA2A0013 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733505449-930404 X-HE-Meta: U2FsdGVkX1/gIDbJjvOzXjnWTXOgluN1ODQvWk/gEjRvzjlcW0HixoKxXRdK4fqNFLpnw9zsJEOuH+9Bvx9BYXqogPCBr6j6o9daoWv+I0C3HgHDFfusu53n7UfXH3CJ9mm1D2Py2tsryda1I5BzZZ+oYhwCQj2R1AEw/CnInQXtK2E8XebqCDT7CUQ2LGEV/xlu0e7XVeA4CLwOrBKq0kju6/cyg4EnQNeNIZQnLMB/+dN2qkBa6NFu620PoFOYLEcBw3sl8K1fUC8ZCTVtsld7d5cb+zOERc2PfpGefg+xA8LZMrwZdCIbc6Ei4jjB/qfZ93zRl1q9fVQK8Jq2Aw5z/BXF/0sfyj86a76b0mtV61PAEnyDtRaB1SaC3IituesDtKOCD2X9uczYhexZy05hTrW9qZGWSQlL+isgbSh+9aJ2Vi1oundFiUASzyHo8n/2OZwlHDu9OggTq7fWCFI9RI1HpUGgbFpkclrLvKiMVNxbTO8jIJR2oZuy7qyW2FG7/p0fGMKB+Uzf89FR23Bek/hS+oPUG0rGKRyX7C/l+VoE9ZO4DTqQGz6vpqGvr1pkHe2bO8MAXNS7Gw73sUid/mIDAPk78jlPMkOpF/BvxfoM7V1yGA8Q8zvejP3a13LjldVbp+utM1HAk52Tc+Quv8JGZz8V2akT+PBQSayx9cnQEREEZVBiloV8iBlMkLcOKBGEyz8Jt4056JrF/uBHHbEZqPp6WUTWG13jLbeQSFzy8IxdVvNAa/fK48OUxMX7mbuzoE0bpzmiMCES2xoMWwrFMhoLTpUcLLwDCC7Pi02bDaTvMb2TLAEl8oLTyabYyfRqKV8h5VMAGxXXOV2GmSJVLJcZggSC7D+u85PR4cjP/EPA2taMv/y8JH3CaSKBS+lghy1FLDcWZQpCuPEPmZP1f0en8XRcOV6xLg6vhe/5iyQDPSCkanJF3W0a4qawCkcHmwT4+dWXxU/ d/34eD7N ILT7ZjnPUtlQo8CXLKGlB393G4A/8aL1N22Vix1pwSwmLhlNgB95uOC+xMwWzB/eOo+o6OVe/FQJl52sL8AzqiUqtu2qtiD/tWJqZUOtag/cXauc7Vw6QkE6NfW9NW64oHCJenCW6magIDLme9pPq+o/C6DdWhLjk7WDpsBIyX9QfItJFn+sw+FBdK+l1AQZm5ortYPc3WMRJJ3wX7ottZ05+32dywLX5uXFLblajAc76I82r9Ag9IenHwre1BG0V8FPUk9hPctlkqNsVxdMbiUZ1JC09/1xczm7LoaBqT5ea21M= 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 Tue, Dec 03, 2024 at 08:31:47AM -0700, Jens Axboe wrote: > If RWF_UNCACHED is set for a write, mark new folios being written with > uncached. This is done by passing in the fact that it's an uncached write > through the folio pointer. We can only get there when IOCB_UNCACHED was > allowed, which can only happen if the file system opts in. Opting in means > they need to check for the LSB in the folio pointer to know if it's an > uncached write or not. If it is, then FGP_UNCACHED should be used if > creating new folios is necessary. > > Uncached writes will drop any folios they create upon writeback > completion, but leave folios that may exist in that range alone. Since > ->write_begin() doesn't currently take any flags, and to avoid needing > to change the callback kernel wide, use the foliop being passed in to > ->write_begin() to signal if this is an uncached write or not. File > systems can then use that to mark newly created folios as uncached. > > This provides similar benefits to using RWF_UNCACHED with reads. Testing > buffered writes on 32 files: > > writing bs 65536, uncached 0 > 1s: 196035MB/sec > 2s: 132308MB/sec > 3s: 132438MB/sec > 4s: 116528MB/sec > 5s: 103898MB/sec > 6s: 108893MB/sec > 7s: 99678MB/sec > 8s: 106545MB/sec > 9s: 106826MB/sec > 10s: 101544MB/sec > 11s: 111044MB/sec > 12s: 124257MB/sec > 13s: 116031MB/sec > 14s: 114540MB/sec > 15s: 115011MB/sec > 16s: 115260MB/sec > 17s: 116068MB/sec > 18s: 116096MB/sec > > where it's quite obvious where the page cache filled, and performance > dropped from to about half of where it started, settling in at around > 115GB/sec. Meanwhile, 32 kswapds were running full steam trying to > reclaim pages. > > Running the same test with uncached buffered writes: > > writing bs 65536, uncached 1 > 1s: 198974MB/sec > 2s: 189618MB/sec > 3s: 193601MB/sec > 4s: 188582MB/sec > 5s: 193487MB/sec > 6s: 188341MB/sec > 7s: 194325MB/sec > 8s: 188114MB/sec > 9s: 192740MB/sec > 10s: 189206MB/sec > 11s: 193442MB/sec > 12s: 189659MB/sec > 13s: 191732MB/sec > 14s: 190701MB/sec > 15s: 191789MB/sec > 16s: 191259MB/sec > 17s: 190613MB/sec > 18s: 191951MB/sec > > and the behavior is fully predictable, performing the same throughout > even after the page cache would otherwise have fully filled with dirty > data. It's also about 65% faster, and using half the CPU of the system > compared to the normal buffered write. > > Signed-off-by: Jens Axboe > --- > include/linux/fs.h | 5 +++++ > include/linux/pagemap.h | 9 +++++++++ > mm/filemap.c | 12 +++++++++++- > 3 files changed, 25 insertions(+), 1 deletion(-) > > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 40383f5cc6a2..32255473f79d 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -2912,6 +2912,11 @@ static inline ssize_t generic_write_sync(struct kiocb *iocb, ssize_t count) > (iocb->ki_flags & IOCB_SYNC) ? 0 : 1); > if (ret) > return ret; > + } else if (iocb->ki_flags & IOCB_UNCACHED) { > + struct address_space *mapping = iocb->ki_filp->f_mapping; > + > + filemap_fdatawrite_range_kick(mapping, iocb->ki_pos, > + iocb->ki_pos + count); > } > > return count; > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h > index f2d49dccb7c1..e49587c40157 100644 > --- a/include/linux/pagemap.h > +++ b/include/linux/pagemap.h > @@ -14,6 +14,7 @@ > #include > #include > #include /* for in_interrupt() */ > +#include > #include > > struct folio_batch; > @@ -70,6 +71,14 @@ static inline int filemap_write_and_wait(struct address_space *mapping) > return filemap_write_and_wait_range(mapping, 0, LLONG_MAX); > } > > +/* > + * Value passed in to ->write_begin() if IOCB_UNCACHED is set for the write, > + * and the ->write_begin() handler on a file system supporting FOP_UNCACHED > + * must check for this and pass FGP_UNCACHED for folio creation. > + */ > +#define foliop_uncached ((struct folio *) 0xfee1c001) > +#define foliop_is_uncached(foliop) (*(foliop) == foliop_uncached) Honestly, I'm not a fan of foliop_uncached or foliop_is_uncached. The first one because it's a magic value and can you guarantee that 0xfee1c001 will never be a pointer to an actual struct folio, even on 32-bit? Second, they're both named "foliop" even though the first one doesn't return a (struct folio **) but the second one takes that as an arg. I think these two macros are only used for ext4 (or really, !iomap) support, right? And that's only to avoid messing with ->write_begin? What if you dropped ext4 support instead? :D --D > /** > * filemap_set_wb_err - set a writeback error on an address_space > * @mapping: mapping in which to set writeback error > diff --git a/mm/filemap.c b/mm/filemap.c > index 826df99e294f..00f3c6c58629 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -4095,7 +4095,7 @@ ssize_t generic_perform_write(struct kiocb *iocb, struct iov_iter *i) > ssize_t written = 0; > > do { > - struct folio *folio; > + struct folio *folio = NULL; > size_t offset; /* Offset into folio */ > size_t bytes; /* Bytes to write to folio */ > size_t copied; /* Bytes copied from user */ > @@ -4123,6 +4123,16 @@ ssize_t generic_perform_write(struct kiocb *iocb, struct iov_iter *i) > break; > } > > + /* > + * If IOCB_UNCACHED is set here, we now the file system > + * supports it. And hence it'll know to check folip for being > + * set to this magic value. If so, it's an uncached write. > + * Whenever ->write_begin() changes prototypes again, this > + * can go away and just pass iocb or iocb flags. > + */ > + if (iocb->ki_flags & IOCB_UNCACHED) > + folio = foliop_uncached; > + > status = a_ops->write_begin(file, mapping, pos, bytes, > &folio, &fsdata); > if (unlikely(status < 0)) > -- > 2.45.2 > >