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 63B7FD6DDCC for ; Fri, 15 Nov 2024 04:01:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 471C06B007B; Thu, 14 Nov 2024 23:01:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FB216B0082; Thu, 14 Nov 2024 23:01:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 275CB6B0083; Thu, 14 Nov 2024 23:01:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 04E536B007B for ; Thu, 14 Nov 2024 23:01:32 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 67C99C137C for ; Fri, 15 Nov 2024 04:01:32 +0000 (UTC) X-FDA: 82786979562.02.A01B351 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf18.hostedemail.com (Postfix) with ESMTP id 7AE971C0012 for ; Fri, 15 Nov 2024 04:01:10 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="g/6or+BK"; spf=pass (imf18.hostedemail.com: domain of sunjunchao2870@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=sunjunchao2870@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731643201; 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=SBbOMZKSEglULtzjYYUceNSTFC5l18/XBMumWX6ysKc=; b=5WsVOP3gPw9cl8hc1KhkvHjQ/eEmmGcLVZJJuxiQVKQ6RXhgsc+2wkAixN03FNt4E3XtDX o2CJj/wIr9JEob464Pgdetko6TOVHxFJHgIjQ3U1rdJHuOgpZAofNXBQVY9AsNcUn0I57I MBs2WtoUGV4ZBVViM4LSY+cxwd83ZVE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731643201; a=rsa-sha256; cv=none; b=Jm+mT1rlYsQMBH/U8usssEICik8x62QztXlsE2xbxSxdFZhzTiNQFIAOHKJtDigP96XBha X6vZpFSOpuJDT1UKtz0zeGqMQdQZq1RVZdsoiJSbPmgsexbnmg0hcSyBvIZCYaNqIDuIWy P+cGf20FIQCi12suiyTdI0NQVA77ssM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="g/6or+BK"; spf=pass (imf18.hostedemail.com: domain of sunjunchao2870@gmail.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=sunjunchao2870@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-20cd76c513cso12497105ad.3 for ; Thu, 14 Nov 2024 20:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731643289; x=1732248089; darn=kvack.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=SBbOMZKSEglULtzjYYUceNSTFC5l18/XBMumWX6ysKc=; b=g/6or+BKUxwtZo1ou2am9V99PoLzVZQCHa8EE9/ed5LKxo+K+OjPLjBgdTtWY05y1v 8xd29U+PehTg86yPu+PgjihN8OXfVAod+E3f7bJuyOcRLvDi+OGYlhQ1RVD5cIJvKMe6 fJaUBAINewNfjr/xgs2+HY1qrSIW2JX/gm5Q7y2+r3iK3VVMoYeG133RWS87b2uxYk4M CMfsSv41UfytiDi/9ghUIZv20X3s6WKsLbPQahe2NYcRSMynU/K+wm96Pwq/avxz7IhM IvJTQcvdZAGtAxlrjAKsj8LfsXohZckDtNm0UFuIiFxeaOLA3wIRtHsyjzgYbR1FyemW 6s1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731643289; x=1732248089; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=SBbOMZKSEglULtzjYYUceNSTFC5l18/XBMumWX6ysKc=; b=DNiKg1MgB30WQpg8R1P4DFAEeHPKv1FNknWFwiQF2vN2gR6svNzTw3W1CFgjFnSd62 4rvHRLFpSdvFYc7xlj5ZduzAAqsoaWM4iFY3Aj4A1F1CM/Ya6cJoJJRY7X/qI8pixAHS 3itOK1uwdzMRVwk14kVhic35XQIZrf+uzad/yjuqm97CULQFemIkNL4ZgCGNOKJLj68q ffSQtsPEYUYzP0YQRNO1K0AcMKt4qf/hiYuXi9Gi6//HEXZ2eY9AErMrazsDklw2inRl 202SgiHheYG8SZU7MthO8DLG2iOrKux99YOyiNP8M/vR4bClY0Bp8DX4pHoyQbWCQdkk m9AQ== X-Forwarded-Encrypted: i=1; AJvYcCWLYVXcwJlKNFMfPOo6oMgJwoLedvFQDQRYjQcUjs67As+NHEs1HgrZ9L7C6SKtZCoXoGBGaZ9J0Q==@kvack.org X-Gm-Message-State: AOJu0YxnXF7FbGFG9pAIGmfgFZodMnz68Le/5x1ZWNQaqUgcUert2IXA mkyZukH4FiNgt+uFP4eua1UPRoUzDhJKAwr2v7hK20FbxOlsy0WE X-Google-Smtp-Source: AGHT+IGIGDCtkGXvHsXcS/UCbj1fAXsOFtXspIdyEuLCS6WlpXb/8B43cROPn6gVvB1e1TRaXbciRw== X-Received: by 2002:a17:902:ec88:b0:20c:da98:d752 with SMTP id d9443c01a7336-211d0d6fcdfmr17849335ad.16.1731643288821; Thu, 14 Nov 2024 20:01:28 -0800 (PST) Received: from [10.172.23.43] ([206.237.119.150]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-211d0dc5d7bsm3902325ad.36.2024.11.14.20.01.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Nov 2024 20:01:28 -0800 (PST) Message-ID: <8b47ebabf12a531f2fa24a7671df5e569b82adb7.camel@gmail.com> Subject: Re: [PATCHSET v5 0/17] Uncached buffered IO From: Julian Sun To: Jens Axboe , 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, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-xfs@vger.kernel.org, bfoster@redhat.com Date: Fri, 15 Nov 2024 12:01:23 +0800 In-Reply-To: <20241114152743.2381672-2-axboe@kernel.dk> References: <20241114152743.2381672-2-axboe@kernel.dk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Rspamd-Server: rspam10 X-Stat-Signature: 6bwisgo6914y78fk19i3pzqgai8ck54e X-Rspamd-Queue-Id: 7AE971C0012 X-Rspam-User: X-HE-Tag: 1731643270-129565 X-HE-Meta: U2FsdGVkX1+N6a2dBeyebOZhohTocTLCuC9V4SUSyykM+QB5EZZ1nf7HyahG5ekYeUTBn5NCqsG4aY3jFO9TDaUrAXjxgJpBh1JwnjYSsTLeBegSkbT2P2BpYVilOqC+O/ZEgVxoFK9Sj8t0LktGX+wEd1POfEmCeJKSHCh6fBj9uKzKF7+ZbhUFH2vGQAT/UE/28MaXvsttxuE3dW+PGL9kVkX+ZSAmT2FTrHhoU5hpLMfn9THyWSfDEM7/Y85S8p1l8WmWMmkT7BWgKnLZ1kryVvOmQinIiQgVdzhI/MGq3Zpu5lbbJa0P7eJpegKv+UYkDSElIFD0sHlAMziHHcZtHZFOwMKah6/Bh+5SphbN2lOGhfeoJgiXUlB6CG2WlvQ3AbDLukgIlHu3D4iq7cbpPZgrPeuKYzEaMqtV+JZSSgRz+eXlsPXXP8vRxc4LMCya5JxozSC3mVjz9j9dvXktu6Xbe0Tpovbsjs29Vm+ZLdCMvRo7l52B2YzpUGa33M0uAcTojGt4khYDD8Ransh9noLE6PmpWyiYyBlqIWMBpnAQOxYRT+ZcUlkmFNt+GKou2mTB7N1s/V26ep877Bc3RMBhW6I6YfNk2QJVLBzo2yhAsB8mLic/JY30BcRDb21gcmbwbQPopUBNzifPksHOgRY6JvLgfo1YZaCxhSf1z4w277IJaw1t9HeU4oYhhFqSd5KfIyb/2/qdQh8Y1Lkv5I/C47y3Z74gYNGuxwD00nIQSSUV8ALevDxEj2LrlW5d3pDuPtZ7OZAdBFYpbfLAtpF+FjG7DgNFsCT+BEaXQnAsigAJDOtCakteteQ/eLXd403ayjcwsyaFdSr4oXH8mB/KwkgVhmbilwjd2NB047NBxUGo+mJhgrjRFJaGSa08L8boQ7nyMWXewD46e1W2JxqBzIXvy0yNNU7wvI3fARenGyuOS6LCQGssoCKl5oEcIqlOg2nfkJWxJWK tyJo8N6N Ds0c6gl8cVns9Q0KpMAvPExpV1RYjxRIxasY8DLEpBsGanM7nfzLw90/3tSJSqaYxlck/6w5vCLXUJCij5uyEhtrc1wIikfMctyoCL2/hUBdQcWx2tvQ1ppXyocRQwekAtb20YkhoZ6RIiz6GsiS7+pBrKabO28sZfl7Xi9FRuz3zDlVIPxTk4Gbn900Ce6U80cn6uYC8uCRuKOjWx3Pd5wObPhTAZCbD4/rZist/gGTLprzhKEvnsro29/KD6+osqKS80Vig3T6hXS9cShdh2LE1kv6VtV4iWG/kP4GeBqT0eRJtDV3R2ZngTX2yRh5xt3Bfri/ZYZacYo4OV2GQ1U9aENOtjbznTXnVWjrVZ2hMdVqGggefZSffXd6ITHG17Rs+AMrnkflUPUVVZel6DGGF2UCsz7KTk/OLUXd+/EeQjWweKFMddyWz++OgWMCK7NKy 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 Thu, 2024-11-14 at 08:25 -0700, Jens Axboe wrote: > Hi, >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 10 adds support for filemap RWF_UNCACHED > writes, and patches 13..17 adds ext4, xfs/iomap, and btrfs support. >=20 > 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. Once we're into > the 6.13 merge window, I'll split up this series and aim to get it > landed that way. There are really 4 parts to this - generic mm bits, > ext4 bits, xfs bits, and btrfs bits. >=20 > And git tree for the patches is here: >=20 > https://git.kernel.dk/cgit/linux/log/?h=3Dbuffered-uncached.7 >=20 > =C2=A0fs/btrfs/bio.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 4 +- > =C2=A0fs/btrfs/bio.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 2 + > =C2=A0fs/btrfs/extent_io.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0 8 ++- > =C2=A0fs/btrfs/file.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 9 ++- > =C2=A0fs/ext4/ext4.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 1 + > =C2=A0fs/ext4/file.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 2 +- > =C2=A0fs/ext4/inline.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 7 +- > =C2=A0fs/ext4/inode.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 18 +++++- > =C2=A0fs/ext4/page-io.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 28 ++++---- > =C2=A0fs/iomap/buffered-io.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |=C2=A0 15 ++++- > =C2=A0fs/xfs/xfs_aops.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 7 +- > =C2=A0fs/xfs/xfs_file.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 3 +- > =C2=A0include/linux/fs.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 21 +++++- > =C2=A0include/linux/iomap.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0=C2=A0 8 ++- > =C2=A0include/linux/page-flags.h=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 5 = ++ > =C2=A0include/linux/pagemap.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0 14 ++++ > =C2=A0include/trace/events/mmflags.h |=C2=A0=C2=A0 3 +- > =C2=A0include/uapi/linux/fs.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0 6 +- > =C2=A0mm/filemap.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 114 ++++++++++++++= +++++++++++++++---- > =C2=A0mm/readahead.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 22 +++++-- > =C2=A0mm/swap.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2= =A0=C2=A0 2 + > =C2=A0mm/truncate.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 35 ++++++---- > =C2=A022 files changed, 271 insertions(+), 63 deletions(-) >=20 > Since v3 > - Use foliop_is_uncached() in ext4 rather than do manual compares with > =C2=A0 foliop_uncached. > - Add filemap_fdatawrite_range_kick() helper and use that in > =C2=A0 generic_write_sync() to kick off uncached writeback, rather than n= eed > =C2=A0 every fs adding a call to generic_uncached_write(). > - Drop generic_uncached_write() helper, not needed anymore. > - Skip folio_unmap_invalidate() if the folio is dirty. > - Move IOMAP_F_UNCACHED to the internal iomap flags section, and add > =C2=A0 comment from Darrick to it as well. > - Only kick uncached writeback in generic_write_sync() if > =C2=A0 iocb_is_dsync() isn't true. > - Disable RWF_UNCACHED on dax mappings. They require more extensive > =C2=A0 invalidation, and as it isn't a likely use case, just disable it > =C2=A0 for now. > - Update a few commit messages >=20 Hi, Hello, the simplicity and performance improvement of this patch series are really impressive, and I have no comments on it.=C2=A0 I'm just curious about its use cases=E2=80=94under which scenarios should i= t be used, and under which scenarios should it be avoided? I noticed that the backing device you used for testing can provide at least 92GB/s read performance and 115GB/s write performance. Does this mean that the higher the performance of the backing device, the more noticeable the optimization? How does this patch series perform on low-speed devices? My understanding is that the performance issue this patch is trying to address originates from the page cache being filled up, causing the current IO to wait for write-back or reclamation, correct? From this perspective, it seems that this would be suitable for applications that issue a large amount of IO in a short period of time, and it might not be dependent on the speed of the backing device? Thanks, --=20 Julian Sun