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 9764CD3ABD1 for ; Mon, 11 Nov 2024 17:25:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3017D6B0092; Mon, 11 Nov 2024 12:25:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B19A6B0095; Mon, 11 Nov 2024 12:25:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A0776B0096; Mon, 11 Nov 2024 12:25:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EFB386B0092 for ; Mon, 11 Nov 2024 12:25:06 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8BA25A1A26 for ; Mon, 11 Nov 2024 17:25:06 +0000 (UTC) X-FDA: 82774488678.12.812F39C Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id E7CEDC0008 for ; Mon, 11 Nov 2024 17:24:22 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=m0WTjtB3; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731345843; a=rsa-sha256; cv=none; b=Y1cokKhdsyfQafX7EBlQLHAKvLO06JFJ3OU4MVdTpscpWcWMmIDARESPpbbCMLxvd5ky6W JYEbxqEsMzLdAyCsSGTEXuNMMRbL5b+A1xAU0/VgHBTO3Y9XgdyI01AeeZqYoexsWWtPKw 1B7NBciAMem1ZhbNLIfyL2DSIUvIpzo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=m0WTjtB3; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731345843; 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=oJUvmaLMls4QyVzgHd/CRZouPmHJ7haStEfbTpiaAew=; b=JKVVrreeCYTY2XDSrvryosWrVhOhgjY3vXXvUZsXwY4vAD5YzGqj6Ci9rXZL20qub0F2FS 5JtCDjZZ2zDZCKgVvijLuhgOEeohaYRzH2z2pmbamWH95T970IL0aWhRhS9EdScBCrei1R Qlians4orF+CeqZFhr+wIcJWul8AdPE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=oJUvmaLMls4QyVzgHd/CRZouPmHJ7haStEfbTpiaAew=; b=m0WTjtB3Wzbx5YCUos/R4iC9nd RsodqXy5/xaK5T2nSiM70xxtagh1+X9FDg/T0WngMNVYuBCDSNDQwFNS3ylYNvsS/+Rn87wsNNHQC zVrF0HIhto6Jpbr6Fr0bywwxtMlftHam8UkVpKnE95siACzcS/duhgakqZAx9kNVqvMscs97IX8Xp t3zEvAlCA1feLMpFJX6ElXvbeUWfsW1VSsWsGBpic8Z3jl82OLsdj0O+aMgvFboOyg+3HNFx3yiqm 0MLERIyBN//COqsniZUidzmAiuyF9VOngXQlivO5BmFneBBd9HwXs+0USuUphA7uYcdBVXV1+oXy+ 0dT3KpVw==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tAY9t-0000000D4Dx-1vG2; Mon, 11 Nov 2024 17:25:01 +0000 Date: Mon, 11 Nov 2024 17:25:01 +0000 From: Matthew Wilcox To: Jens Axboe Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, hannes@cmpxchg.org, clm@meta.com, linux-kernel@vger.kernel.org Subject: Re: [PATCHSET v2 0/15] Uncached buffered IO Message-ID: References: <20241110152906.1747545-1-axboe@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241110152906.1747545-1-axboe@kernel.dk> X-Rspam-User: X-Rspamd-Queue-Id: E7CEDC0008 X-Rspamd-Server: rspam11 X-Stat-Signature: h1dr35upju6666wbwy75mpbrwnyg4ufe X-HE-Tag: 1731345862-307285 X-HE-Meta: U2FsdGVkX1/mUuIhqivGlr9qBAUTKfF1BDymW8+7GM8sohybPvgYCLtLZ7CI9Z3lR13+e0qw0QjAuXHxwx4b7oeH/qjB1B20QMQN7XUeFh/WvMf8o/VzrRHZCLaZjytdz1timMdmYk5v0+1x08rxu+vvef5jj9XQar5D004lj6X3ypy/I8wzhuOkTY+HnOGQ4Tc9ZoY9u6UV5xTiFVvO77GAAVkxF43pYIytlecxgypaAvQHXtBe+5Je5x+T57B71m3oT12HkEKKNp7q2OAtWyAqtGGUpc7CiG3DY243aK3E9tTdUiAMm7AuiLrWUmnLx6tgeT6lkmdmF+f1S8imSxhbv4yLd0MsQ1LBl8l+W5nobLeOopDgWRya7nfa7EbMyzcakCHK9O0eD4IWkhirZojk5p0kCTVkLvUfriV3/GRY4IPLdjT6T1Ho9PcGPRXgwcdtbP4tIcESoQD7vvh7IoGsJiiMvb014eo/WVCBP368k28yQsVqt/8rACmPL9PP0bmBcII2EK2l2xZVENcnAR1l0QMDyZjMGKqMre/Po54Tf35jnIJtlVFn9x3kKOLm0wbwgbv5ul/4DwI1nv0vLICvoK7JuJP1qaT5JcC5ACLQ8LrSiILZY+Co2RxMe5g0gh4Dsb9OcYZRtQrblg/rb4pJGkrkCuaRCP28UyqgnRpinW5QP4wkNTMWKfAKueYZsue8RwXZtDq/g0y5PqMcuHnFQYqZV0jis208lC4Gnpc4kYiQ8AcQf3e/bh9ScA7cqb13URc3Ah0UKynCvVpwBmz7HMpVd97SMs/vIjbNzQAXWIvvZNFNH46ZjmPxvkXvqWzP6f3y38r+yKN20SK1Ai8TpBfaivkUz0zw02NW6UAYl09RdAwu7KOQ1JuKMK4euDv2+n3CPo0dWLak9rPzJs5tFDDJiy4EsdfpYWd9a4kdQJskTBk72MyDWnh+uIw8s3G5qH6TeElNkZUDp15 ZVcaK0NW +ZdF9hPC6whhEF/9fB0SSmUooQ4lyxk2vtN3HWFGTsLUCPwLG0b0+7c4iIT92HJNr2xa+0rvj4E/+0vXV4n8G3d1VToDXSY7blAV97XVNAsOCG8aazVR9N9nIVER6Ko0VKqHvvPhuo14iLNx8Qz+KfUCRzQdXEjHeJJJobQNOREW5JLd2ATLDID6c2MyEo1pCzlxVCWKTA8VccxxJ50kDgqjhiYU+oX1n8IZX 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 Sun, Nov 10, 2024 at 08:27:52AM -0700, Jens Axboe wrote: > 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. Today's a holiday, and I suspect you're going to do a v3 before I have a chance to do a proper review of this version of the series. I think "uncached" isn't quite the right word. Perhaps 'RWF_STREAMING' so that userspace is indicating that this is a streaming I/O and the kernel gets to choose what to do with that information. Also, do we want to fail I/Os to filesystems which don't support it? I suppose really sophisticated userspace might fall back to madvise(DONTNEED), but isn't most userspace going to just clear the flag and retry the I/O? Um. Now I've looked, we also have posix_fadvise(POSIX_FADV_NOREUSE), which is currently a noop. But would we be better off honouring POSIX_FADV_NOREUSE than introducing RWF_UNCACHED? I'll think about this some more while I'm offline.