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 912B4D64072 for ; Fri, 8 Nov 2024 17:45:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D3E36B00A9; Fri, 8 Nov 2024 12:45:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 084116B009E; Fri, 8 Nov 2024 12:45:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E66666B00A9; Fri, 8 Nov 2024 12:45:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C510E6B0082 for ; Fri, 8 Nov 2024 12:45:17 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 48702A0EE5 for ; Fri, 8 Nov 2024 17:45:17 +0000 (UTC) X-FDA: 82763653392.05.76B51B2 Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) by imf16.hostedemail.com (Postfix) with ESMTP id 609CD180024 for ; Fri, 8 Nov 2024 17:44:38 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b="vd/k2oIa"; dmarc=none; spf=pass (imf16.hostedemail.com: domain of axboe@kernel.dk designates 209.85.167.170 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731087789; a=rsa-sha256; cv=none; b=HgzXvw7idJ1tVMOX6bb49IFt1Wwi6mF2ap1uSHNe8FuIzipAGQhTmmW0gCZrfHJGM7IheS Yo9Bc5QmF1ArwD8T1muPXULNVy4IH05DRI363MlWiZ2x/y/IlPvAZZ/C3tqbfjbmdy1HxO UOg9Z9bLetYUwwCYQN7tz2Ig+713iXU= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b="vd/k2oIa"; dmarc=none; spf=pass (imf16.hostedemail.com: domain of axboe@kernel.dk designates 209.85.167.170 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731087789; 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=yIbPsCAwFh4QrXCyUX2OKNpcITEfUEDm/2X9pcKM5mY=; b=JzwwkaxkQkzUYKm+XmGVLgQXwsZHChzs1kAfQFDau2QdzdCkMfeHy1tsILA43j2e+WeMNZ 905V0/Sg2sJsNX05eonTuD5ALG1OJwQ9yGpRt38hmZ33sSd7mrE0WhNflNpvhorqZ2vQ8f Mvivyc2KXIaUPqz2/SsAiT0b4CfhO+o= Received: by mail-oi1-f170.google.com with SMTP id 5614622812f47-3e60d3adecbso1456423b6e.2 for ; Fri, 08 Nov 2024 09:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1731087913; x=1731692713; 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=yIbPsCAwFh4QrXCyUX2OKNpcITEfUEDm/2X9pcKM5mY=; b=vd/k2oIa1PNvchqAFa2jQDnBxcm5IF4/f9QZalHn8hjNDICEZvAuLVAkK1rs7/JLf3 i5DkIVjFG0d23dk297HmRXUyT/4EUxpXyEROCW2lTQ7QAMGtn2ZdCQoorZErPCZq7mCf 9/5AfWbcwdOTYX59uyxiG62HDK3bhNOo8aJ0sqhwA5pErloDBkMVLHT9XuBqWd5h25ON DPKqq8tq36IvzXM98kquxvltYvXdgIPNSZOE5349XQWxpVK5Z143THHnKXVv+ktIbKj1 99vTNXbfJHNFoiU5wk1dahfWpPJBNJ9ZHXFV53Hnh0jLv9iRMMPqkqL5VXg1lnSqDtMQ pFlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731087913; x=1731692713; 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=yIbPsCAwFh4QrXCyUX2OKNpcITEfUEDm/2X9pcKM5mY=; b=blcjR51cV1sQvr6sUfDBx2FWYcofCavcyNZ50kyRMajYWwWplkYI9B1TR5MxQcWM+X QxRcOwWp0p7lJjEZQN+b/Ie3XnqpnzOH5KcmkFNSexbiKys2LVSGVwK47CHVORMxIhU/ 5ZZUyfzb/yaZjlgdgDYdJYup1vSBpRG08hZFkpwDB9pWxFYPneAKgh9T7tZi/E8uE/5W N4rSvK9l8RGuUnsNl6bGcBLVmGM2j6AugaAypm8xGTdeG/SqGFPr1gxBHm0l9X3m5tSL 7ioY2z5HUgpIYQO1wiasZ2pylCbe+ge9514JtxGh7XrwtHR8Y4ymeRLBZ7hbpN5kRxWy JJ+g== X-Gm-Message-State: AOJu0YxGOt4EU5KrlsSETJD2jls8J7JDMo9BgRwnpEkE5n3AcWfvO08x QM3o3Z4sgvAvi9NfdYNl9aDvF4el/SPZ2XH59ZR0rmoBLmq2QWMuORpGygFNlJcW3JdLleeDOty If04= X-Google-Smtp-Source: AGHT+IELfXTZchf5ws2966+qT0G3hRimxoOiA9u248rT/yieDoC8CAYaekbdxhxB2O+jrHp/dXR7Jg== X-Received: by 2002:a05:6808:11c7:b0:3e5:d591:c9a9 with SMTP id 5614622812f47-3e7947031famr4902007b6e.26.1731087913567; Fri, 08 Nov 2024 09:45:13 -0800 (PST) Received: from localhost.localdomain ([96.43.243.2]) by smtp.gmail.com with ESMTPSA id 5614622812f47-3e78cd28f80sm780969b6e.39.2024.11.08.09.45.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Nov 2024 09:45:12 -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 Subject: [PATCHSET v4] Uncached buffered IO Date: Fri, 8 Nov 2024 10:43:23 -0700 Message-ID: <20241108174505.1214230-1-axboe@kernel.dk> X-Mailer: git-send-email 2.45.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 609CD180024 X-Stat-Signature: 1b4azthsbj614yfawt59phkgxc43mjhz X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731087878-384280 X-HE-Meta: U2FsdGVkX18vZV3zKDrwO2kDXjK4k7JLcQI8tesWNgmEhuIpbAzwsd1tqiw2v82E3Uu8SgQ5u1ZABPtkmdBWSP9V9a2K3AOyVE+FZkpOmrhEKsvbdvX3r9nYQ3u8jyko52eqLbtdQRjkOffaakbZwl7jvX1lFGvVXj7+e8znIz2qfEvftgYWWHjc4Fty5wpXM118y+Ly5rJgxNyrDhpamJ4llZ9/AJSuhKkCCnE6cjiGhWmrB81wNvGzhr0NlGX4TATodtjlFNkycVqPIM7ozL9tIt/DvM2H7XKCXwvbcbt4FoN4oqTRpkCQlNVjlLJXbgOQih1ICZMSLnI+T+8d0G09mBZ/awwxWgl3+T3onnK7Uj7K8VG9TtCOVf/3UH2GTO3YrR0KWZGT7jbUzdjtWQGBkK7uYL05EeDSoe83otYZ4xzCswPY8RPrNlzm1uwIMLzyKlfPVkP/9GBfu4A9xCTTDM0K50rsq995+1U8YEwZR76sAkzLxalQQxehI2BXfLmLgN3qMiiE/EK1HENJBpmaYvH8HRpkpprP62pJU20z4rwt8BpyXutMbFPxPaVr4Sv4hFcf3MqWXon5n+WxPvB/7BmoYUUI9WbT49OdRXeJhVKaapulnJCcSjai8kzT9M46OCVH5mv1kGwVf0m8URuTQJksFPAo1DSkxnSdmwoWbfb607qnAT/62aeHP+MOGA0MnX0jhypAQCJdQekPfNrhTwm2LmAlorMW7Pym07PprwGN1MQif4oytXDc48fDfTwjNuBi535Tv8o4+6d3qufMGGBGHZ0xic+h0E8Sw+K99eH7ObA2sTzWDeWHtyHFi5ScQ3yKt0b680vxdJFRbzyVtH+BspTTFHiYeaJD2flqX7n8xVFO6QM1lUyM8noto8dtrEQDQGvFrSNjYiTuTIoDs8cx08b+PMVwfVAkmlgiQhdnwXxhIxTTuoXWe/NnC1OtVWw7QjJhe1NU+cV nlhiy3my abEWfQ/0Dca7fnHs7axs53kHG8jrciYWmR95VYWhlNa4X6wsMGOrsuJFAVUxUo7Vu19llgMfM/u3w8c3KStv+V1JRdz5nsSgOqMV+e5GtlH7DP31JtOJk7HMez8DYL3tafgZnnQgcTbN1Ua7V1VXCdKAiuhjC4VM1VDYKSZg2NlnnymdO9501du9zdYW8RkZbKqHd62sPKVTECaD5AbxZJ3UJKvwzSCjSD3HMHGiHX7Tono7Cd8SwbxV284ScMCKt+ArgSkfoiQEGTL/OmAym0gUtb28LaY3XEAIFZRiBF0rJ/uXYaDOxOFTqffK55NR8cMS+aNQWukKtJzvhd7emy7LDevSsRkwheEGmyssy3hsLfqE= 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. Normal users do big backups too, edit videos, etc. 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. 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 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. The goal with this patchset was to make it less special than before. I think if you look at the diffstat you'll agree that this is the case. 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 patch 11 adds iomap support uncached writes. Finally patches 12 and 13 do the simple 1-liner writing up for ext4 and XFS. Git tree can be found here: https://git.kernel.dk/cgit/linux/log/?h=buffered-uncached.4 fs/ext4/file.c | 2 +- fs/iomap/buffered-io.c | 12 ++++++++- fs/xfs/xfs_file.c | 3 ++- include/linux/fs.h | 10 +++++++- include/linux/iomap.h | 3 ++- 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 | 58 ++++++++++++++++++++++++++++++++++-------- mm/readahead.c | 22 ++++++++++++---- mm/swap.c | 2 ++ mm/truncate.c | 9 ++++--- 13 files changed, 111 insertions(+), 27 deletions(-) -- Jens Axboe