From patchwork Tue Dec 10 16:24:49 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 11282937 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A0A48109A for ; Tue, 10 Dec 2019 16:25:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6CF6C222C4 for ; Tue, 10 Dec 2019 16:25:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kernel-dk.20150623.gappssmtp.com header.i=@kernel-dk.20150623.gappssmtp.com header.b="LTyUtTOi" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6CF6C222C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.dk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 78F026B2D37; Tue, 10 Dec 2019 11:24:59 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 73FBE6B2D38; Tue, 10 Dec 2019 11:24:59 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6551C6B2D39; Tue, 10 Dec 2019 11:24:59 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0239.hostedemail.com [216.40.44.239]) by kanga.kvack.org (Postfix) with ESMTP id 50E2A6B2D37 for ; Tue, 10 Dec 2019 11:24:59 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id E99238249980 for ; Tue, 10 Dec 2019 16:24:58 +0000 (UTC) X-FDA: 76249755876.27.knife71_e4d1c100cf51 X-Spam-Summary: 50,0,0,703c07dbe203c6e7,d41d8cd98f00b204,axboe@kernel.dk,::linux-fsdevel@vger.kernel.org:linux-block@vger.kernel.org,RULES_HIT:41:355:379:541:967:968:973:988:989:1260:1311:1314:1345:1381:1437:1515:1535:1542:1711:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2693:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4031:4250:4605:5007:6261:6653:7974:8603:9025:9040:10004:10226:11232:11657:11658:11914:12043:12291:12296:12297:12517:12519:12679:12683:12903:13137:13150:13161:13229:13230:13231:13845:13894:13972:14039:14095:14096:14181:14394:14721:21080:21324:21325:21444:21627:21740:21773:30045:30054:30079,0,RBL:209.85.166.195:@kernel.dk:.lbl8.mailshell.net-62.14.0.100 66.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: knife71_e4d1c100cf51 X-Filterd-Recvd-Size: 5012 Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Dec 2019 16:24:58 +0000 (UTC) Received: by mail-il1-f195.google.com with SMTP id u17so16665749ilq.5 for ; Tue, 10 Dec 2019 08:24:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=NL2wx8OhT9nqgeYI97q9VsOTFKCtkP5TFUuqwTv6H6w=; b=LTyUtTOiDdot1XqLMl7i53d11nkIkpHsXZo5aA5qNQorELxc9mAR1aNsmM5j49z653 ZyfAKvcNIpn1QLWUtIJWJTWvGsFYz9Vi7ZUKgfVki4us09AZkRrdPaTzyk+l0Uj0IHku 5NvFFAaXeBYP9Woq9eCHZMJZ4s5Cj2UOgxNzWtlOuK0mCUUofkS0QaxBBB7CP6G4it0P PDteFrR7FCMx+hQ7BOW+4f8mEsHSJj4kVM+sH7x/xHqjdFzZ2Z9t9y/1ym7bs7xZxScO pKMMgV2UsdiOS5yIu8odu9AUzU7WGUIu0q30XMeOp7GP8DzAeoXj+2WJA49O3UI/WEgi aihQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=NL2wx8OhT9nqgeYI97q9VsOTFKCtkP5TFUuqwTv6H6w=; b=e5Ja5Ul8JdvdFTJ81tFM8WVFiWqTo/u9OFdrUxXG2Ueo2SsJ2+Ezhd6eZOb24PDtES bm0EfQrtG9x9UjrIxXtDCz5WddWxCXaViDj9Ht4jE5DXRFE0sFfJKdhmSIAcD5vMa17s wz6WNo+TB1bCkMAehRawA0GXSzHyT9WSpi2hBfe6h0QtN/VQGz3mbeaLigOGzzgCCEMy L6A9Eyj6tnV5TJqZGObtnZBiGWamHfPXohIIaB3/7/r/YlNljQYk8a5jCWajhvs3u3el OJymFY4y0mVLCp8fMW88fTZjRTrprqlJNKsRYQqnsg8rkPTyTtGoN2U6eiDhsn7BAF2j a1NA== X-Gm-Message-State: APjAAAXNvH+Rm9vk0FAmJAipZ2vihCNcebg+aT8YNqzKw/hrZLrk1VvX x8UkfOfm282ze8fxZRv/HyhufYKH2hMO7g== X-Google-Smtp-Source: APXvYqzFCnW3bCJ9SgM7zc9uOwPn6XurQF380D0hDP/vO67nas52IiaHd40QcaYT8aulE0gULhfCqw== X-Received: by 2002:a92:d7c1:: with SMTP id g1mr35930204ilq.192.1575995096800; Tue, 10 Dec 2019 08:24:56 -0800 (PST) Received: from x1.thefacebook.com ([65.144.74.34]) by smtp.gmail.com with ESMTPSA id y11sm791174iol.23.2019.12.10.08.24.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Dec 2019 08:24:56 -0800 (PST) From: Jens Axboe To: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org Subject: [PATCHSET 0/5] Support for RWF_UNCACHED Date: Tue, 10 Dec 2019 09:24:49 -0700 Message-Id: <20191210162454.8608-1-axboe@kernel.dk> X-Mailer: git-send-email 2.24.0 MIME-Version: 1.0 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: Recently someone asked me how io_uring buffered IO compares to mmaped IO in terms of performance. So I ran some tests with buffered IO, and found the experience to be somewhat painful. The test case is pretty basic, random reads over a dataset that's 10x the size of RAM. Performance starts out fine, and then the page cache fills up and we hit a throughput cliff. CPU usage of the IO threads go up, and we have kswapd spending 100% of a core trying to keep up. Seeing that, I was reminded of the many complaints I here about buffered IO, and the fact that most of the folks complaining will ultimately bite the bullet and move to O_DIRECT to just get the kernel out of the way. But I don't think it needs to be like that. Switching to O_DIRECT isn't always easily doable. The buffers have different life times, size and alignment constraints, etc. On top of that, mixing buffered and O_DIRECT can be painful. Seems to me that we have an opportunity to provide something that sits somewhere in between buffered and O_DIRECT, and this is where RWF_UNCACHED enters the picture. If this flag is set on IO, we get the following behavior: - If the data is in cache, it remains in cache and the copy (in or out) is served to/from that. - If the data is NOT in cache, we add it while performing the IO. When the IO is done, we remove it again. With this, I can do 100% smooth buffered reads or writes without pushing the kernel to the state where kswapd is sweating bullets. In fact it doesn't even register. Comments appreciated! Patches are against current git (ish), and can also be found here: https://git.kernel.dk/cgit/linux-block/log/?h=buffered-uncached fs/ceph/file.c | 2 +- fs/dax.c | 2 +- fs/ext4/file.c | 2 +- fs/iomap/apply.c | 2 +- fs/iomap/buffered-io.c | 75 +++++++++++++++++------ fs/iomap/direct-io.c | 3 +- fs/iomap/fiemap.c | 5 +- fs/iomap/seek.c | 6 +- fs/iomap/swapfile.c | 2 +- fs/nfs/file.c | 2 +- include/linux/fs.h | 9 ++- include/linux/iomap.h | 6 +- include/uapi/linux/fs.h | 5 +- mm/filemap.c | 132 ++++++++++++++++++++++++++++++++++++---- 14 files changed, 208 insertions(+), 45 deletions(-)